Ports and health checks

The port is one of the most important settings of an HTTP project. Zenifra needs to know which port should receive traffic inside the application.

Main rule

The value configured in the Port field must match the port where the application listens.

Node.js example:

const PORT = process.env.PORT || 3000;

app.get('/health', (req, res) => {
  res.json({ status: 'ok' });
});

app.listen(PORT, '0.0.0.0');

FastAPI example:

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

Best practices

• listen on 0.0.0.0
• configure in the console the same port used by the code
• avoid relying only on localhost
• create a simple /health route
• do not make /health depend on slow or unstable services
• log the port during startup

Application health check

Even when the platform does not require a specific health check route, the application should expose a simple route for operational validation.

A good /health route should respond quickly and return success when the HTTP process is ready to receive traffic.

Common response:

{ "status": "ok" }

For diagnostics, you can also expose version, commit, or ZENIFRA_INSTANCE_VERSION, as long as you do not expose secrets.

Common failures

Next steps

• Production deploy
• Quickstart — Node.js
• Quickstart — Python
• Troubleshooting

FAQ

Does Zenifra define the port automatically?

No. Configure the project port explicitly and make the application listen on it.

Can I use a route other than /health?

Yes. /health is only a simple convention that is easy to test.

Should I test the database inside the health check?

For a basic HTTP readiness route, prefer a fast response. Deep database tests can exist in another protected route or internal tool.