---
title: Publishing and its command line
scope: 3dmk
type: documentation
subject: publishing
group: Systems
status: current
version: "2.1.3"
source: https://3dmk.com/documentation#publishing
author: Nick Olson
contact:
  email: 3dmk@3dmk.com
  site: https://3dmk.com
license: CC BY 4.0
license_url: https://creativecommons.org/licenses/by/4.0/
attribution: Nick Olson, 3dmk.com
---

# Publishing and its command line

Publishing is the release route for the stack. It turns a version into a release tag, one image, and a deployment on each host. Two parts carry the work: the `core-publishing` service and its command-line interface (CLI), `core-publishing-cli`. The route exists so that every environment runs the same tested build.

## Role

The CLI starts every release step from a developer machine. One command versions a repository in four steps: a version bump, a commit, a release tag for major and minor versions, and a push. The bump covers every file that declares the version.

A deploy takes a release tag, never the working tree. One image builds once on core-docker-1 for both hosts. A development deploy runs it there. A production deploy ships the same image to core-docker-aws-1. Each host supplies its own configuration and secrets.

Guards protect running work. A deploy holds while a running game server still has open sessions. A deploy also fails before any change when a host lacks free disk space.

The `core-publishing` service holds release state on core-docker-1. It registers each repository’s publishing manifest. It tracks one stack per environment. It records deployment history, health, and drift.

## Parts

Each part owns one job.

| Part | Member | Job |
|---|---|---|
| `set-version` | CLI | Bumps, commits, tags, and pushes a release |
| `deploy-dev` and `deploy-prod` | CLI | Deploy one release tag to core-docker-1 or core-docker-aws-1 |
| `publish-dev` and `publish-prod` | CLI | Send the new files of an assets release to its content site |
| `view-dev` and `view-prod` | CLI | List each host’s containers with their image versions |
| API server | Service | Registers manifests and runs stack operations |
| Deploy worker | Service | Runs queued deploy and destroy jobs one at a time |
| Health monitor and drift detector | Service | Check stack health every 60 seconds and drift every 5 minutes |

## Data

The CLI keeps no state. Git holds the versions and release tags. Each target keeps its running release and the one before it.

The service stores its records in PostgreSQL. Redis holds its deploy queue and short-lived health results. The service keeps these main records.

| Record | Holds |
|---|---|
| Manifest | A repository’s registered manifest, its version, and its validation result |
| Stack | One repository in one environment, with its state, health, and lock |
| Deployment | One operation with its commit, release tag, image tag, status, and duration |
| Drift event | A difference between a stack’s expected and actual configuration |

A stack moves through the states `planned`, `applying`, `running`, `stopped`, `failed`, `destroying`, and `destroyed`.

## Connections

The CLI hands each release to the Core bootstrap, which builds, ships, and starts it. The route exchanges data with these systems:

- Registry: The CLI looks up each repository and the development host there.

- GitHub: A release tag must exist locally and on the remote before a deploy starts.

- Consul and Vault: The target host’s pair supplies the configuration and secrets for each release.

- PostgreSQL: Each deploy applies the repository’s database patches before its containers start.

- Model Context Protocol (MCP) gateway: It exposes the CLI as its `publishing` tool.

The service finds PostgreSQL, Redis, and Vault through Consul.