Deployment

Zenifra publishes HTTP applications from Git repositories or OCI images. For Git, use GitHub or a Forgejo connection. The source defines how the application is built, updated, and versioned.

Choose the right method

Use a Git repository when the team wants to publish directly from source code. Choose GitHub or Forgejo according to the available connection. On both providers, choose Manual, Automatic by branch, By Tag, or By Release; only one mode can be active at a time. See the update modes for GitHub and Forgejo.

Use OCI image when the image is already generated by external CI, when you need to promote immutable tags, or when you want to control the artifact outside Zenifra.

Publication flow

Video: publishing an HTTP application from an OCI image.

1. Git: select the connection, repository, and branch.
2. OCI: provide the public or private image.
3. Port: configure the port where the application listens.
4. Variables: register secrets and configuration.
5. Online: validate the application at the public URL.

How a new version goes live

On every deployment, whether a new build, an OCI image change, or a change that restarts the instances, Zenifra replaces the instances without interrupting traffic:

1. a new instance starts with the new version while the previous one keeps serving
2. requests start reaching the new instance; if it does not accept connections on the project port yet, the previous instance serves the request
3. the previous instance stays up for 30 seconds after the new one starts and then receives the SIGTERM signal

To make the most of this switch:

• make the application listen on the project port as soon as it is ready to serve; if it takes longer than 30 seconds to start, some requests can fail during the switch
• handle SIGTERM to finish in-flight requests before exiting
• applications that do not serve HTTP, such as queue consumers, are updated normally too: the switch never waits for the port to answer

With more than one instance, they are replaced one at a time.

What to validate after deployment

• the application responds on the public URL
• build logs do not show errors
• application logs appear in the console (available on every plan)
• CPU, RAM, storage, and HTTP requests appear according to plan
• custom domain points to the correct destination, when configured
• Git updates happen automatically only according to the selected mode: branch push, new tag, or published release

In Git projects, build logs live in the Build logs section of the project page. They are different from the running application's logs.

Health checks

To continuously validate an HTTP application and automatically restart an instance when a failure is confirmed, configure Health checks for HTTP projects. The feature is available from the Premium plan up, checks a GET route every 1 minute, expects a 2xx response, and keeps failure history for 30 days.

Next steps

• GitHub Deployment
• Deploy from Forgejo
• OCI image deployment
• Private registry
• Deploy and Automation CLI
• Automatic by branch
• Rollback