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 3000If 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.
| Source | Best for | Attention |
|---|---|---|
| GitHub | Teams publishing from the main branch | runtime, branch, and auto-deploy are defined during creation |
| OCI image | Pipelines that already generate Docker images | use immutable tags to track versions |
Step 3: create the HTTP project
In the console, click Create Project and fill in:
- organization where the project will be created
- project source
- runtime or image
- HTTP port
pre-build,build, andstartcommands when the source is GitHub- environment variables
- 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:
- create the database
- copy the full URI from the console
- manually configure
DATABASE_URLin the HTTP project - restart or redeploy the application if needed
- 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:
- new build started
- build logs have no errors
- application responds on the public URL
- 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
- 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.