Applications

An application is the saved definition of a workload on one server. It describes where the workload comes from, how its container should run, and how Serversinc should replace it during a deployment.

A deployment applies that definition. The resulting container is the running instance you inspect, restart, and read logs from.

Choose an application source

Docker image

Use a Docker image application when an image already exists in Docker Hub or another registry. Set the image name and default tag, then add registry credentials if 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. Install the Serversinc GitHub App for the organisation, grant it access to the repository, then choose a branch.

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

Configure the runtime

Application configuration includes:

• Environment variables and secret values
• Bind mounts and named Docker volumes
• Docker networks
• Port mappings
• Container labels
• CPU and memory limits
• Registry credentials

Saving one of these settings changes the desired configuration. Redeploy the application to apply that change to its container. The dashboard marks applications whose saved configuration differs from the last deployed configuration.

Environment variables and secrets

Secret values are handled separately from ordinary values. Treat reveal actions as access to production credentials. You can also paste a .env file to add several variables at once; check overwrite choices before saving.

Storage and networks

A bind mount maps a host path into the container. A named volume asks Docker to manage the stored data. Both can be mounted read-write or read-only.

Attach an application only to networks that exist on its assigned server. Port mappings publish container ports on the host; domains normally route traffic through the managed reverse proxy instead.

Add a domain

Set a domain in application settings to route traffic to the application. Serversinc stores the routing configuration as container labels and applies it on the next deployment.

Before deploying, point the domain’s DNS record at the server and confirm which container port should receive traffic. Certificate issuance depends on the domain resolving correctly and the validation request reaching the server.

Deploy the application

A deployment may pull an existing image or build one from GitHub. Serversinc then creates a candidate container and replaces the current container according to the selected strategy.

Recreate

Recreate stops the current container before starting its replacement. It is direct and works for workloads that cannot run two copies at once, but it causes downtime during the swap.

Rolling

Rolling starts the replacement before retiring the current container. During the swap, both containers can exist at the same time. Use a health check path to hold 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.

Read deployment and application logs

Deployment logs explain the build, pull, start, health check, and swap stages. Container logs show the application’s current stdout and stderr. Check deployment logs when a release fails; check container logs when a successfully deployed process later misbehaves.

Trigger a deployment externally

Each application has a trigger URL, deploy key, and secret for CI systems. The secret is shown once. Store it in the CI provider’s secret manager.

Rolling the secret invalidates the previous value immediately. Existing pipelines must be updated before their next run.

Control the running workload

Start, stop, or restart an application from its action menu. These controls act on the application’s current container. Container pages expose the observed image, state, server, runtime configuration, and live logs.

A container is replaceable runtime state. Put lasting configuration on the application, then deploy it.

Next steps

• Servers: inspect the host running the application.
• Databases and backups: add persistent services and backups.
• Automation: trigger deployments from CI, the CLI, API, or MCP server.
• Reference: check deployment lifecycle and application settings.