Production deploy on Zenifra

This guide connects the recommended path from a new account to a production-ready application. Use it when you need deploy, database, observability, domain, and billing in a single flow.

Prerequisites

• active account on Zenifra
• available credit (including the promotional credit for new users, while the promotion is available) or a card configured for automatic charges; the Free plan does not require credit
• GitHub or Forgejo repository, or OCI image ready to publish
• known start command, such as npm start, uvicorn main:app --host 0.0.0.0 --port 8000, or equivalent
• HTTP port where the application actually listens

Important: Zenifra routes traffic to the port configured in the project. The application must listen on that same port.

Step 1: prepare the application

Before creating the project, confirm locally that the application starts without missing files.

For Node.js, prefer reading the port from an environment variable:

const PORT = process.env.PORT || 3000;
app.listen(PORT, '0.0.0.0');

For Python with FastAPI, use an explicit start command:

uvicorn main:app --host 0.0.0.0 --port 8000

If the application uses a database, queue, or external services, list the required variables before deployment. Do not commit passwords, tokens, or keys to the repository.

Step 2: choose Git repository or OCI image

Use Git repository (GitHub or Forgejo) when you want Zenifra to build from source code. This path works well for applications that change frequently and can benefit from Automatic by branch mode.

Use OCI Image when you already have a ready image generated by an external CI pipeline, or when you want to control the production artifact by tag.

Step 3: create the HTTP project

In the console, click Create project and fill in:

1. organization where the project will be created
2. project source
3. runtime or image
4. HTTP port
5. pre-build, build, and start commands when the source is a Git repository
6. environment variables
7. plan, instances, and storage according to the workload

After creation, open the *.clients.zenifra.com URL and validate a simple route, such as / or /health.

Step 4: connect the database

If the application uses PostgreSQL, MariaDB, Analytics (ClickHouse), or Valkey (Key-Value, Cache, and Queues), create the managed service and copy the connection details from the console. Connections require TLS.

Zenifra does not automatically inject DATABASE_URL into the HTTP project. The correct flow is:

1. create the database
2. copy the full URI from the console
3. manually configure DATABASE_URL in the HTTP project
4. restart or redeploy the application if needed
5. validate the connection through logs and an application route

For engine, replica, storage, and failover details, see Database.

Backup: Zenifra does not offer automatic backups with restore from the console. Before going to production, set up your own dump or export routine (for example, pg_dump or mysqldump) and test the restore.

Step 5: validate logs, metrics, and version

After deployment, check:

• application logs
• build logs, when available
• CPU, RAM, and storage
• number of HTTP requests received by the application
• ZENIFRA_INSTANCE_VERSION, when used by your code

Application logs are available on every plan; metrics, from the Premium plan. Logs are read live from the instances, with no stored history; send what you need to keep to your own service. For details, see Observability.

In Git projects, open Build logs on the project page to follow dependency installation, pre-build, build, and publish steps. Use application logs separately to investigate failures after start.

Step 6: configure domain and access

Every project receives a Zenifra URL. For production, you usually also configure a custom domain.

Before sending real traffic:

• configure DNS at the domain provider
• validate propagation
• keep the Zenifra URL as an operational fallback
• review IP whitelist and blacklist for administrative or internal projects (from the Premium Plus plan)

Step 7: validate the deployment mode

If Automatic by branch is selected, make a small change on the configured branch and push it. To validate the tag and release options, follow the GitHub Deployment or Forgejo Deployment guide.

Validate:

1. new build started
2. build logs have no errors
3. application responds on the public URL
4. new version is visible in logs or in a diagnostic route

In Manual, By Tag, and By Release modes, a branch push does not start an automatic update.

Step 8: monitor billing

Before keeping the project in production, review:

• project billing mode
• available credit
• credit card as billing fallback, when configured
• database and persistent storage cost
• AI consumption, if the application uses Zenifra models

For credit, monthly, yearly, and hourly rules, see Payment Models.

Next steps

• Checklist before production
• GitHub deployment
• OCI image deployment
• Security, privacy, and reliability
• Limits and quotas

FAQ

Can I use Zenifra in production?

Yes. Use this guide with the deployment, database, observability, security, and limits pages to validate whether the plan and configuration fit your scenario.

Do I need to configure DATABASE_URL manually?

Yes. Managed databases show connection details in the console, but the HTTP project must receive DATABASE_URL manually as an environment variable.

How do I know the new deploy is live?

Use logs, metrics, the public URL, and a version identifier such as ZENIFRA_INSTANCE_VERSION or a /health route that exposes the application version.