Applications

An Application in Serversinc represents a deployable project (such as a web service, API, database, or background worker) that runs on a single server. Applications act as the central unit for deployment, configuration, and monitoring.

Types

Applications can be created in two ways:

Docker Application

Deploy directly from a Docker image.

Requires an image name (optionally with tag).
Best for prebuilt services, custom images, or apps you don’t need to build from source.

GitHub Application

Deploy from a GitHub repository.

Serversinc will build a Docker image from your repo using Buildpacks.
Best for projects you want to update via pushes to a repository.

Key Differences

Feature	Docker Application	GitHub Application
Source of truth	Docker image	GitHub repo
Build step	None	Runs a buildpack container on server
Deployment trigger	Manual	Manual or on push via Github Webhooks

Domains & Traefik

When you add a domain to an application:

If Traefik is not installed on the server, Serversinc will automatically install and configure it.
The domain is bound to your application’s container through Traefik labels.
Traefik automatically provisions and renews SSL certificates for your domain via Let’s Encrypt.

Domains require a valid DNS A record pointing to your server’s IP address.

Traefik Labels

Serversinc generates Traefik labels on your application’s containers to handle:

Routing traffic from your domain to your container.
Setting up TLS certificates.
Routing requests to the correct internal container port (see Ports).

Using Cloudflare

If you are using Cloudflare for DNS management, ensure that the A record for your domain is set to “DNS only” (grey cloud) to allow Let’s Encrypt to verify domain ownership. Alternatively, you can configure DNS-based verification in Traefik that works with Cloudflare’s proxy (orange cloud).

Configuration

Labels

Key-value metadata attached to containers for Traefik or other orchestration.
Serversinc automatically manages Traefik-related labels, but you can add custom labels as needed.

Serversinc automatically adds metadata labels to each container:

Name	Value	Notes
`com.serversinc.app_id`	Application ID	Internal reference
`com.serversinc.workspace_id`	Workspace ID	Internal reference

These labels are used internally to manage and identify containers.

Volumes

Bind paths or named volumes into your container. Useful for persistence (e.g., /data, logs, database storage).

Environment Variables

Define runtime variables passed to your container.

Name	Value	Notes
`APP_ENV`	`production`	Example
`DB_HOST`	`db.internal`	Database connection string

Containers & Applications

Each Application can have one or more Containers, which are the actual running instances of your app.

Containers inherit config from the Application (env vars, volumes, labels).
Deployments eventually result in one running Container (see below).

👉 See the Container Reference for full details.

Rolling vs Recreate Deployments

When deploying a new version of an application, you can choose between two strategies:

Recreate (default): Stops the existing container(s) before starting new ones. This is simpler but may cause downtime.
Rolling: Starts new container(s) before stopping the old ones, allowing for zero-downtime deployments.

When using Rolling deployments, you may notice two containers running simultaneously during the transition period.

Running Commands

You can execute commands inside an application’s container (e.g., artisan migrate, npm run build) by clicking into the Container’s Commands tab.

Commands are run inside the Docker container.
You can run commands on any container for the application.
Exit code and logs are captured and viewable in the dashboard.

Deployments

Deployments are how you update an application.

Build
- Only applies to GitHub Applications.
- Builds a Docker image from your repository and tags it.
Deploy
- Runs a container using a specific image.
- Applies env vars, volumes, and labels.
- Can happen after a build or directly for Docker Applications.

Settings

Ports

Applications can expose one or more ports.

Defined as container:host.
Example: 3000:80 means the container listens on port 3000, mapped to host port 80.
The first container port is used in Traefik labels when binding domains.

Container Port	Host Port	Notes
`3000`	`80`	Common for web applications
`5432`	`5432`	Common for PostgreSQL
`6379`	`6379`	Common for Redis

Here, the application container listens on port 3000, which is mapped to port 80 on the host. Traefik will route HTTP traffic from your domain to port 3000 in the container.

Alerts & Notifications

Serversinc can notify you when containers for an application:

Stop unexpectedly.
Start again.

Alerts are sent through your configured notification channels.

👉 See Notifications Reference for setup details.