Deploying a Service

A service is an application running in a container with its configuration. Deploy from GitHub or a container registry by opening a project and clicking Deploy Service.

Project

Select the project that will contain the service.

Deploy to Server

Choose a server or create one. A server can run multiple services within its resource limits.

Services

Click Add service to configure each service. You can deploy several at once.

Deploy source

Choose a GitHub repository, a container registry image, or a preset with prefilled configuration.

Deploy from GitHub

You can deploy services by selecting a repository from GitHub. A Dockerfile is optional — if your repository contains one, Sliplane will use it. If it doesn't, Sliplane will automatically detect your application's stack and build it for you using Railpack.

Select GitHub in the deploy form. You need repository admin access; see GitHub integration for permissions.

Select a Repository

Choose a repository from the dropdown. If it is missing, click Configure Repository Access and grant Sliplane access on GitHub. Return to the dropdown and click Refresh List; changes may take a minute to appear.

Select a Deploy Branch

Select the branch to deploy. New commits deploy automatically unless you disable Automatically deploy new commits in the service settings.

Dockerfile Path

Sliplane detects and prefills your Dockerfile path. Check it for renamed files or monorepos, and include the filename, such as /app/Dockerfile.

Leave it empty to build with Railpack when your repository has no Dockerfile.

Docker context

The build context is the directory used by Dockerfile commands such as COPY . .. It defaults to /, the repository root. For a monorepo, select the folder whose contents the image needs.

Deploy from a Registry

Select Registry to pull an image from an OCI-compatible container registry.

Image URL

Enter registry/namespace/image:tag, without http:// or https://:

• Docker Hub: docker.io/namespace/image-name:tag
• GitHub Container Registry: ghcr.io/namespace/image-name:tag

Official Docker Hub images use the library namespace. You can also search Docker Hub by image name and select a version from the results.

Credentials

For a private image, select or add registry credentials. Credentials belong to the team.

Expose Service

Enable this for public websites, APIs or other internet-facing services. Sliplane supports one public port per service and detects it automatically. Set PORT explicitly if needed, for example PORT=3000.

Disable it to allow connections only from services on the same server. Connect through the internal hostname shown in service settings.

Networking protocol

Use TCP/HTTP for websites and HTTP APIs. Choose TCP or UDP for services using those protocols directly, such as databases.

Health check route

For HTTP services, set a route that returns a 2XX response to a GET request without authentication. The default is /; /health is another common choice. Health checks use the detected port or your PORT setting.

Sliplane checks the route before switching traffic to a new deployment, then every minute. Three consecutive failures trigger an email notification.

Environment Variables

Set environment variables as key-value pairs or paste a .env file. They are available during build and runtime. If no .env exists in the project root, Sliplane creates one from your configured variables.

Values are stored encrypted. Mark a variable as secret to prevent its value from being viewed again.

Reserved keys

Sliplane provides deployment metadata and recognizes the following configuration variables. SLIPLANE_COMMIT_HASH and SLIPLANE_DOMAIN are platform-provided values. The other variables below let you configure deployment behavior.

PORT: Set this to your application’s listening port inside the container (1–65535). Sliplane uses it to route requests and run health checks. Your application must listen on the same port.

SLIPLANE_COMMIT_HASH: The git commit hash of the current deploy.

SLIPLANE_DOMAIN: The managed domain (e.g. your-service-name.sliplane.app) of the service.

SLIPLANE_SKIP_CACHE: If set to true, the Docker build cache will be skipped.

SLIPLANE_GRACE_PERIOD: Time in seconds that Sliplane will wait for your container to start, before cancelling the deploy.

SLIPLANE_USER_ID: Specify the user id that owns volumes, that are attached, e.g. 1000

SLIPLANE_GROUP_ID: Specify the group id that owns the volumes, that are attached e.g. 1000

Variables in environment variables

Reference another variable using ${VARIABLE_NAME} or $VARIABLE_NAME:

DOMAIN=${SLIPLANE_DOMAIN}
DATABASE_URL=postgres://${DB_USER}:${DB_PASSWORD}@${DB_HOST}:${DB_PORT}/${DB_NAME}

Volumes

Attach a volume for files that must survive deployments. Set its mount path to the absolute path of the container folder, including your application’s working directory where applicable. See Volumes for attachment and removal.

Service Name

Enter a name for your service. The default is your repository name. Your subdomain will be your-service-name.sliplane.app if available.

Override CMD

Optionally replace the image’s CMD. Enter a command string, such as echo "Hello World!", rather than array syntax like ["echo", "hello world"].

Using the Docker Command Parser

In the Add service form, click the terminal icon and paste a Docker run command or Compose file. Click Add service to import the configuration.

You can provide environment variables referenced as ${VARIABLE_NAME}. For services that reference each other, the parser tries to substitute Sliplane internal hostnames using $SERVICE_NAME.INTERNAL_HOST in environment variables.

What happens if a new deploy fails?

If a new build fails, the existing deployment keeps running. For services without mounted volumes, Sliplane starts and checks the replacement before switching traffic. Services with mounted volumes require the old container to stop before the replacement starts, so a startup failure can cause downtime. Inspect the failed deployment’s logs before retrying.