Deploy an application

Create an application, then deploy it to turn its configuration into a running container.

Deploy your first app

Use a public Docker image and keep the defaults. You can change everything later.

1. Open Applications, select New application, then Docker image.
2. Choose your server and enter a name.
3. Enter a public image, such as nginx, and the tag latest.
4. Keep the default settings. The default strategy is Recreate, with a health check.
5. Save the application, then select Deploy.
6. When the deployment status is Completed, open Logs and check that the container started.

To put the app on a domain, see Add a domain. The rest of this page explains each option.

Before you begin

You need a connected server, and either a Docker image that the server can pull or a GitHub repository connected through the GitHub App.

Choose an application source

Docker image

Use a Docker image application when a registry already contains the artifact you want to run.

1. Open Applications, select New application, then Docker image.
2. Choose the target server and enter a name.
3. Enter the image without its tag, such as ghcr.io/acme/api.
4. Set the default tag.
5. Add registry credentials only when the image is private.

You can override the tag for an individual deployment without changing the rest of the application configuration.

GitHub repository

Use a GitHub application when Serversinc should build from source.

1. Install the Serversinc GitHub App from Settings → Integrations.
2. Grant the installation access to the repository.
3. Open Applications, select New application, then GitHub app. Choose the target server, the repository, and the branch.
4. Enter the runtime configuration required by the repository.

GitHub deployments record the source branch, commit ID, and commit message. A push to the configured branch can start a new build and deployment.

Run and verify the deployment

1. Save the application.
2. Review variables, volumes, networks, ports, labels, and resource limits.
3. Select Deploy.
4. Follow the deployment stages while Serversinc builds or pulls the source, creates a candidate container, checks it, and performs the swap.
5. When the deployment completes, open Logs and confirm that the process started normally.
6. Test the application’s real entry point, such as its domain or health URL.

If a release fails before the swap, the deployment log shows the stage and failure. If it completes but the process misbehaves later, use the container log. See Deployments and logs for that distinction.

Choose a deployment strategy

Recreate stops the current container before starting its replacement. Use it for workloads that cannot run two copies at once, or when brief downtime is acceptable.

Rolling starts the replacement before retiring the current container. The server must have enough spare capacity to run both containers during the swap. Configure a health check path so Serversinc can keep traffic on the current container until the replacement responds successfully.

The stop grace period controls how long a retiring container has to finish in-flight work before it is forced to stop.