Production

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 balance, initial credit, or configured payment method
  • GitHub repository or OCI image ready to publish
  • known start command, such as npm start, uvicorn main:app --host 0.0.0.0 --port 3000, 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 3000

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 GitHub or OCI image

Use GitHub Repository when you want Zenifra to build from source code. This path works well for applications that change frequently and can benefit from auto-deploy.

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.

SourceBest forAttention
GitHubTeams publishing from the main branchruntime, branch, and auto-deploy are defined during creation
OCI imagePipelines that already generate Docker imagesuse immutable tags to track versions

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 GitHub
  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 or MariaDB, create a managed database and copy the connection details from the console.

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.

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

Logs and metrics can vary by plan. For details, see Observability.

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

Step 7: push again and validate auto-deploy

If auto-deploy was enabled during GitHub project creation, make a small change on the configured branch and push it.

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

If auto-deploy was not enabled during creation, do not treat pushes as automatic updates for that project.

Step 8: monitor billing

Before keeping the project in production, review:

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

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

Next steps

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.