Checklist before production

Use this checklist before sending real traffic to an application on Zenifra. It helps review the points that most often cause production issues: port, variables, database, logs, domain, permissions, and billing.

Application

• the application starts locally with the same command configured in the console
• the port configured on Zenifra matches the port used by the application
• the server listens on 0.0.0.0, not only on localhost
• there is a simple health route, such as /health
• dependencies are declared in package.json, package-lock.json, or requirements.txt
• secrets are not versioned in the repository

Deployment

• the selected source fits the flow: GitHub or Forgejo repository for source builds, OCI for ready images
• production branch is correct
• select Automatic by branch only if the watched branch is stable
• OCI image tags identify real versions
• the project port matches the port exposed by the OCI image, such as 80 for the official NGINX image
• build logs were reviewed after the last publication
• operational rollback was planned before critical changes
• the team knows build logs live in Build logs and are different from application logs

Variables and secrets

• DATABASE_URL was configured manually when a database is used
• API keys, tokens, and passwords are stored as environment variables
• variable names match the names used by the application
• production values do not reuse local or test credentials
• the team knows who can edit variables in the console

Database

• engine and version match the application
• storage is sized for production
• storage increase rules are understood
• connection pooling is configured in the application
• migrations were tested before deployment
• connection details were stored securely
• there is your own dump or export routine, with a tested restore, because Zenifra does not offer automatic backups with restore from the console

Observability

• logs appear in the console (application logs on every plan, read live with no stored history)
• CPU, RAM, storage, and HTTP request metrics were checked
• the team knows where to check build logs and application logs
• email alerts were enabled and external alerts or a monitoring routine were defined when needed
• the team follows platform incidents at status.zenifra.com
• diagnostic route shows version or commit when that helps support

Security and access

• organization permissions were reviewed
• members have only the access they need
• API keys were stored securely
• whitelist or blacklist was configured for internal projects (from the Premium Plus plan)
• custom domain points to the correct destination
• incident response ownership was agreed internally

Billing

• credit or payment method is available
• billing mode is understood
• persistent storage cost was considered
• AI usage is limited by budget when applicable
• the person responsible for billing has console access

Next steps

• Production deploy on Zenifra
• Observability
• Security, privacy, and reliability
• Payment Models

FAQ

Do I need to complete every item?

For real production, yes. In test environments, some items can be simplified, but port, variables, logs, and billing should always be reviewed.

Does this checklist replace application tests?

No. It reviews operations on Zenifra. Unit, integration, load, and migration tests remain the project's responsibility.

When should I review it again?

Review it before large changes, plan changes, instance increases, database changes, domain changes, or critical variable changes.