Configuration

Set update behavior from the Settings page. Outpost saves those choices in SQLite and applies them immediately, while Compose remains responsible for the paths and identity needed before that database can open.

Two Kinds of Configuration

1. Runtime behavior — The schedule, label mode, monitor-only mode, cleanup, replacement timing, and private registry sign-ins live in the database. Change them on the Settings page without restarting Outpost.
2. Container bootstrap — The Docker connection, data directory, process identity, time zone, and port remain in Compose because Outpost needs them before it can read the database.

Back up the outpost-data volume to preserve the runtime settings with the account, access tokens, notification destinations, registry sign-ins, and history.

Example

services:
  outpost:
    image: cbnventures/outpost:latest
    container_name: outpost
    environment:
      PUID: "1000"
      PGID: "1000"
      TZ: "Europe/London"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - outpost-data:/data
    ports:
      - "22601:22601"
    restart: unless-stopped

networks:
  default:
    enable_ipv6: true

volumes:
  outpost-data:

After Outpost starts, open Settings to choose the schedule and update behavior, and to add sign-ins for private registries.

Schedule Settings

The schedule runs in the time zone set by TZ, which the next-check line names. Custom (cron) takes six fields, second, minute, hour, day of month, month, and day of week, for example:

• 0 0 4 * * * — Every day at 04:00.
• 0 0 */6 * * * — Every six hours.
• 0 30 2 * * 0 — Sundays at 02:30.

Five-field patterns without the seconds field, such as 0 4 * * *, also work, as do the nicknames @yearly, @monthly, @weekly, @daily, and @hourly.

If a cycle is still running when the schedule comes due, that scheduled run is dropped, not queued. The next one starts at its usual time.

Update Behavior Settings

See Labels and Modes for the label rules and Updates and Rollback for how the timeouts are used.

Data Directory

The dashboard account, runtime settings, access tokens, notification destinations, and private registry sign-ins are kept in the database in the data directory.

You create the account on the first visit, with a setup code from the container log, as shown in Web Dashboard. Destinations are added on the Notifications page, as shown in Notifications.

Only the default /data is created and handed to PUID when the container starts. A custom OUTPOST_DATA_DIRECTORY must already belong to PUID, or Outpost stops at startup with a permission error.

Docker Connection

DOCKER_HOST doesn't support TLS, so a tcp:// address is best kept to a socket proxy on a private network.

Container Identity

Outpost also joins the group that owns the Docker socket, so PGID doesn't need to match the docker group.

Port

Outpost is assigned port 22601 in CBN Ventures' 22600–22699 Docker port block. The dashboard and HTTP API listen on 22601 by default. The examples publish it on every IPv4 and IPv6 address so another computer on the network can reach the Docker host. To use a different port only on the host, change the host side of the mapping, such as "8080:22601".

Set PORT to change the port inside the container too. The image healthcheck follows the same value, so the environment and both sides of the mapping must agree:

services:
  outpost:
    environment:
      PORT: "8080"
    ports:
      - "8080:8080"

IPv6

The examples turn on IPv6 for Outpost's Compose network, so the sign-in limit and the API's rate limit count each IPv6 client by its own address. Docker Engine 27 or later picks the IPv6 subnet on its own, and on a host without IPv6, you can delete the networks block. For docker run, create the network first with docker network create --ipv6 outpost, then add --network outpost.

IPv6 addresses are often reachable from the internet, so it is recommended to check that your router or host firewall blocks inbound connections to port 22601.

Read-Only Root Filesystem

The image can run with a read-only root filesystem, as described in the repository's compose.yml. It needs S6_READ_ONLY_ROOT set to 1, tmpfs mounts for the s6-overlay runtime paths /run and /tmp, and a writable mount at /data:

services:
  outpost:
    image: cbnventures/outpost:latest
    environment:
      S6_READ_ONLY_ROOT: "1"
    read_only: true
    tmpfs:
      - /run
      - /tmp
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

      # Prepared for PUID on every start, so it must be writable.
      - outpost-data:/data

volumes:
  outpost-data:

Validation

The Settings page validates runtime behavior before saving it:

• Timing values — Must be positive whole numbers.
• Container selection — Must be opt-in or opt-out.
• Schedule — Must be a pattern the cron parser accepts. An invalid pattern remains unsaved and is highlighted on the page.

Outpost checks bootstrap values at startup and refuses to start when one is invalid:

• PUID and PGID — Must be whole numbers from 1 to 2147483647, so 0 is refused. The image's init step checks them and logs messages such as PUID must be between 1 and 2147483647.
• TZ — Must name a time zone installed in the image, such as America/Chicago. Otherwise the init step logs Unknown timezone: followed by the value.
• Encryption key — The key file in the data directory must belong to the database, or startup stops, as described in Backup and Recovery. A missing key file doesn't stop startup, because Outpost makes a new key, turns off the authenticator app, and removes the secret fields of notification destinations and the saved registry passwords.

DOCKER_HOST and OUTPOST_DATA_DIRECTORY are not checked for format. A wrong DOCKER_HOST, or a data directory that PUID can't use, stops Outpost at startup instead.