Deploying with `sc`

Install sc and sign in first. This page covers the parts of sc beyond the plain sc deploy: sending part of an application, mounting files, and checking who you are.

Check your account and build

sc whoami
sc version

sc whoami prints your name and email. It then prints the token's label and where sc read the token from, and last the endpoint. sc uses the first of these that you set: --token, $SC_TOKEN, .sc.yml, or the credential store that sc login writes. A stale $SC_TOKEN beats a fresh sc login, so sc whoami is the quick way to find out why you are the wrong user. With no token it fails and lists those four places.

sc version prints the version, the commit, and the build date. It needs no network and no token.

Deploy a few services

By default, a deploy describes the whole application. The deploy removes a running service that the new revision leaves out.

Two flags make a partial revision instead. Every running service that the revision leaves out keeps running.

Flag	What it deploys
`--service <name>`	Only the named service. Repeat the flag to name more
`--profile <name>`	The services of that compose profile, and the services that have no profile

sc deploy --service web
sc deploy --service web --service worker
sc deploy --profile frontend

Use one flag or the other. Both together is an error, and sc refuses it before it packs anything.

An older platform ignores the partial marker and removes the services you left out. Deploy to a current platform.

A sidecar for a service binding that someone removed stays until the next full deploy.

Files from `configs:` and `secrets:`

A compose service can mount files. The platform delivers them as Swarm configs and secrets.

services:
  web:
    image: nginx
    configs:
      - source: site
        target: /etc/nginx/conf.d/site.conf
        mode: 0440
    secrets:
      - source: api_key
configs:
  site:
    file: ./site.conf
secrets:
  api_key:
    environment: API_KEY

Block	Rule
`configs:`	`sc` reads the `file:` or `environment:` source on your machine and puts the bytes into the compose text. The platform refuses a config larger than 500 KB
`secrets:`	`sc` uploads the bytes as a sealed part. The platform encrypts them and keeps them as long as the revision exists
`target:`	A config lands at `/<name>` and a secret at `/run/secrets/<name>` unless you give a path. A relative path is relative to `/` for a config and to `/run/secrets` for a secret
`mode:`, `uid:`, `gid:`	Applied to the mounted file

The platform refuses a deploy in these cases, with a message that names the service:

A service uses a name that the top-level block doesn't declare.
An entry is external:.
A config has no content.
Two files mount at one path.

Earlier versions dropped these keys without an error, so a file never arrived. sc deploy and sc deploy --dry-run also list every compose key the platform ignores, with its service.

Redeploy with no new build

To pick up a changed variable without a rebuild, use the Variables page, or a Model Context Protocol (MCP) client's redeploy_deployment tool. sc deploy --force makes a new revision from your files and rebuilds. See Variables.

Databases and buckets

sc service show <name> prints one managed service: the organization and name, the engine, the state, and the applications bound to it. If two of your organizations use the same name, add --org <slug>. See Managed databases for the rest of sc service.

Deploying with sc