Get your app live in minutes

Neo deploys your Docker app to any VPS over SSH. No agent to install, no platform to sign up for, no infrastructure to manage. If you have a Dockerfile and a server, you're ready.

# 1. Point Neo at your server (installs Docker + Caddy automatically)
neo init root@your-ip-address

# 2. Deploy your project
neo deploy . --domain app.example.com

# 3. Get instant HTTPS (no DNS setup needed)
neo domain my-app --temp
# → https://my-app.your-ip-address.sslip.io

neo init [email protected] -i ~/keys/server.pem

What just happened?

Behind those 3 commands, Neo:

Installation

One command. Supports macOS (Apple Silicon & Intel), Linux (x86_64 & ARM64), and Windows.

Common Workflows

Real examples for the most common tasks.

Deploy a project with a Dockerfile

cd my-project
neo deploy . --domain app.example.com

Migrate from docker-compose

# Auto-generate .neo.yml from your existing docker-compose.yml
neo config generate

# Deploy everything (app + workers + sidecars)
neo deploy . --to production

Local development

# Run locally (wraps docker compose with Neo env loading)
neo dev

# Stop
neo dev down

Day-to-day operations

neo logs my-app                         # stream logs
neo env set my-app API_KEY=sk-123       # set env var (auto-restarts)
neo domain my-app blog.example.com      # set real domain
neo sync my-app                         # sync changes back to .neo.yml

App Templates

Neo ships ten ready-to-run application templates. neo install turns one into a project folder on your machine — it does not install anything on a server. You get an ordinary project you can read, edit and commit, and then deploy like any other.

neo install ghost          # or just `neo install` for a picker
# → asks which folder (default ./ghost)

cd ghost
neo deploy                 # this is the step that reaches your server

What gets written

Available templates

Every image is pinned to an explicit version rather than :latest, so a redeploy can't quietly move you to a new major release. Upgrading is a deliberate edit to the tag in docker-compose.yml.

Project Config (.neo.yml)

The .neo.yml file declares your deployment configuration. Neo can deploy without one — it will infer the port from your Dockerfile, take the app name from the directory, and prompt for a domain — but that configuration then exists only in /etc/neo/state.json on the server. It isn't in your repo, so it can't be reviewed in a pull request, diffed against last week, or restored if the server is lost.

Commit a .neo.yml. Run neo config init to scaffold one, or neo config generate to convert an existing docker-compose.yml. Every individual field is optional; the file itself is what makes a deploy reproducible.

By default Neo builds from a Dockerfile in your project root. If yours lives elsewhere (e.g. Dockerfile.local or docker/Dockerfile), set the dockerfile: field or pass --dockerfile / -f to neo deploy. The build context is always the project root.

name: my-app
domain: app.example.com
port: 8080
https: true

basic_auth:
  user: admin
  password: s3cr3t
  bypass:
    - /api/*
    - /webhooks/*

ssl:
  certificate: certs/fullchain.pem
  private_key: certs/privkey.pem

dockerfile: Dockerfile

env:
  APP_ENV: production
  LOG_CHANNEL: stderr
env_file: .env.production

volumes:
  data: /var/www/html/database          # flat string → named Docker volume
  storage: /var/www/html/storage

workers:
  queue:
    command: php artisan queue:work --tries=3
  scheduler:
    command: php artisan schedule:work

sidecars:
  redis:
    image: redis:7-alpine
    volumes:
      cache: /data
  builder:
    build:
      context: ../builder
      dockerfile: builder/Dockerfile
    volumes:
      output: /output

dev:
  env_file: .env                    # auto-load local .env
  env:
    APP_ENV: local
    APP_DEBUG: "true"
  volumes:
    data: ./local-data             # override bind-mount path

hooks:
  pre_build: npm run build
  post_deploy: echo "Deployed!"

environments:
  production:
    domain: app.example.com
    env_file: .env.production
  staging:
    domain: staging.example.com
    env:
      APP_DEBUG: "true"

name & domain

name: my-app
domain: app.example.com
port: 3000
server: production

env & env_file

Environment variables for your app container. These are merged with other sources during deploy.

env:
  APP_ENV: production
  LOG_CHANNEL: stderr
  CACHE_DRIVER: redis
env_file: .env.production  # secrets go here (not committed)

release New

Commands that run inside the new container, on the server, after it passes its health check but before Caddy switches traffic to it. This is where database migrations and cache warming belong.

release:
  - php artisan migrate --force
  - php artisan config:cache

environments:
  dev:
    release:                          # replaces the top-level list
      - php artisan storage:link
      - php artisan migrate --force

Not to be confused with hooks, which run on your machine (npm build, Slack notifications) and cannot see the deployed container.

dockerfile

Point Neo at a Dockerfile that isn't at the project root — a docker/ folder, a per-environment build file — instead of passing --dockerfile on every deploy.

dockerfile: ./docker/Dockerfile     # used by every environment

environments:
  dev:
    dockerfile: ./docker/Dockerfile.dev   # overrides the top-level one
  production:
    # no dockerfile: here — inherits ./docker/Dockerfile
    server: prod-box

Resolution order, highest first:

Paths are relative to the project root (where .neo.yml lives), and the build context is always the project root regardless of where the Dockerfile sits — so COPY paths stay relative to the project, not to the docker/ folder.

env_encrypted New

Built for Laravel's encrypted environment files. Run php artisan env:encrypt, commit the .env.encrypted it produces, and point env_encrypted: at it — neo decrypts at deploy time, so secrets live in git while the key lives in your password manager. neo env encrypt / neo env decrypt are there for when artisan isn't handy (CI, a machine without PHP); they read and write the exact same format.

# In your Laravel project — key is printed once, save it
php artisan env:encrypt

# No PHP on this machine? Same file, same format
neo env encrypt

# Read it back locally
php artisan env:decrypt
neo env decrypt --stdout

env_encrypted: .env.encrypted   # committed; decrypted at deploy

environments:
  production:
    env_encrypted: .env.production.encrypted
  staging:
    env_encrypted: .env.staging.encrypted

If .env.encrypted exists and you have no env_file and no plaintext .env in the project, neo picks it up automatically — no config needed.

Where the key comes from

On deploy, neo looks for the key in this order and stops at the first hit:

# Save the key once — later deploys never prompt
neo env key set my-app base64:xxxxx
neo env key list
neo env key forget my-app

# CI
NEO_ENV_KEY=base64:xxxxx neo deploy --to production

volumes

Persistent Docker volumes that survive redeploys. Each volume is created as {app-name}-{volume-name}.

volumes:
  data: /var/www/html/database           # flat string → named Docker volume
  storage: /var/www/html/storage
  logs: /var/log/myapp:/var/log/app       # host:container → bind mount on server
  uploads:                                # structured form (optional)
    path: /app/uploads
    mount: /mnt/ssd/uploads               # pin to host path on server

Volumes declared here are also available to workers (automatically shared) and sidecars (via name reference). During neo dev, volumes are auto bind-mounted to ./{volume-name} in your project directory.

workers

Background worker containers that use the same image, env vars, and volumes as the main app — but run a different command.

workers:
  queue:
    command: php artisan queue:work --tries=3 --max-time=3600
  scheduler:
    command: php artisan schedule:work
  websocket:
    command: php artisan reverb:start

Workers are deployed with blue-green rollout alongside the main app. View logs with:

neo logs my-app --worker queue

Workers removed from .neo.yml are automatically deleted on the next deploy.

sidecars

Sidecar containers run alongside your app on the same Docker network but have their own image. They are not exposed publicly via Caddy.

Pre-built image

sidecars:
  redis:
    image: redis:7-alpine
    volumes:
      cache: /data
    env:
      MAXMEMORY: 256mb

Built from Dockerfile

sidecars:
  builder:
    build: ../builder           # string form: path to build context
  custom:
    build:                       # object form: context + dockerfile
      context: ..
      dockerfile: docker/custom/Dockerfile
    volumes:
      output: /output            # shares app volume named "output"
    env:
      WORKER_MODE: "true"

ssl

Bring your own SSL certificate. The cert and key are uploaded to the server and loaded into Caddy on deploy.

ssl:
  certificate: certs/fullchain.pem
  private_key: certs/privkey.pem

Can also be set per-environment (see environments) or via CLI:

neo domain my-app app.example.com --cert fullchain.pem --key privkey.pem

https New

Control whether Caddy serves your app over HTTPS with auto-provisioned certificates.

https: true   # Caddy auto-provisions SSL via Let's Encrypt

edge_https — behind Cloudflare Flexible SSL

When a CDN terminates TLS at its edge and talks HTTP to your origin (Cloudflare's Flexible SSL mode), set edge_https: true. The origin serves plain HTTP, but Neo injects forwarded headers so your app still generates correct https:// URLs.

edge_https: true   # HTTP origin, but app sees X-Forwarded-Proto: https

Neo forwards X-Forwarded-Proto: https, X-Forwarded-Ssl: on, and X-Forwarded-Port: 443 to the container. The CLI equivalent is neo domain my-app --cloudflare-flexible. See Cloudflare Flexible SSL for the full setup.

basic_auth New

Protect your app with HTTP Basic Authentication at the proxy layer. Caddy handles the challenge — the app container is never reached for unauthenticated requests.

basic_auth:
  user: ${NEO_BASIC_AUTH_USER:-admin}   # ${VAR} resolved at deploy; :-default optional
  password: ${NEO_BASIC_AUTH_PASSWORD}   # from env_file / --env / OS env — keep the secret out of git
  bypass:
    - /api/*
    - /webhooks/*

Auth not being enforced?

Caddy applies config through its admin API, so there is no reload step in a healthy setup — a deploy takes effect immediately. If the browser still isn't asking for credentials, check what the proxy is actually serving:

# What Caddy is really serving — AUTH column shows basic or none
neo caddy routes

# Rebuild every route from server state (all apps, or just one)
neo caddy reload
neo caddy reload --app my-app

neo caddy reload rewrites domains, upstream, HTTP/HTTPS mode and basic auth from /etc/neo/state.json. It is the repair tool for a proxy that has drifted from state — after an interrupted deploy, a manual docker change, or a route left over from an older Neo version. neo caddy update is a different thing: it updates the Caddy image, not the routes.

dev New

Local development settings used exclusively by neo dev. Completely ignored during neo deploy.

dev:
  env_file: .env                      # loads your local .env (APP_KEY, secrets, etc.)
  env:
    APP_ENV: local
    APP_DEBUG: "true"
    APP_URL: http://localhost:8080
  volumes:
    data: ./local-data               # short form: override local path for top-level volume
    cache: ./tmp/cache:/tmp/cache    # full form: dev-only bind mount

Env priority for neo dev (highest wins):

1. dev.env — dev-only overrides
2. dev.env_file — dev .env file
3. env — top-level shared vars
4. env_file — top-level env file
5. Auto-loaded .env from project root

Volumes defined in the top-level volumes: section are automatically bind-mounted to the project directory during neo dev. Use dev.volumes to override local paths or add dev-only mounts.

hooks New

Shell commands that run locally at specific points in the deploy lifecycle.

hooks:
  pre_build: npm run build && php artisan test
  post_deploy: curl -X POST https://hooks.slack.com/... -d '{"text":"Deployed!"}'

Hooks run in your local shell with NEO_APP_NAME, NEO_DOMAIN, and NEO_ENVIRONMENT environment variables available.

environments

Named deployment targets that override top-level config. Deploy to a specific environment with --to.

environments:
  production:
    domain: app.example.com
    server: prod-server
    https: true
    env_file: .env.production
    ssl:
      certificate: certs/prod/fullchain.pem
      private_key: certs/prod/privkey.pem
  staging:
    domain: staging.example.com
    server: staging-server
    env:
      APP_DEBUG: "true"
      LOG_LEVEL: debug

# Deploy to production
neo deploy --to production

# Deploy to staging
neo deploy --to staging

# If multiple environments exist and no --to flag, Neo prompts
neo deploy

Environment fields override top-level: domain, server, port, https, env, env_file, env_encrypted, ssl, basic_auth, volumes.

Deploying Apps

Neo builds your Docker image, transfers it to the server, starts the container, and configures routing — all in one command.

# Deploy current directory
neo deploy .

# Deploy with explicit options
neo deploy . --domain app.example.com --env APP_KEY=base64:... --to production

# Deploy a different directory
neo deploy ./my-project

Build strategies

Neo automatically chooses the best build strategy based on your environment.

Env var priority

Environment variables are merged from multiple sources. Higher priority overrides lower.

Zero-downtime deployment

Neo uses blue-green deployment on redeploys:

Domains & SSL

Caddy handles reverse proxying and TLS certificate management. Three ways to set up domains:

# Set a custom domain
neo domain my-app app.example.com

# Assign a temporary sslip.io domain with instant SSL
neo domain my-app --temp

# Use a custom SSL certificate
neo domain my-app app.example.com --cert fullchain.pem --key privkey.pem

# Toggle the origin route mode (without changing the domain)
neo domain my-app --https              # HTTPS at the origin (auto-SSL)
neo domain my-app --http-only          # HTTP only at the origin
neo domain my-app --cloudflare-flexible # HTTP origin behind Cloudflare Flexible SSL

Auto SSL (sslip.io) New

Get instant HTTPS without configuring DNS. The --temp flag assigns {app}.{ip}.sslip.io which auto-resolves to your server.

$ neo domain ghost --temp

  Temporary domain ready!

    URL:  https://ghost.your-ip-address.sslip.io

  sslip.io resolves to your server IP automatically.
  SSL certificate auto-provisioned via Let's Encrypt.

  Replace with a real domain later:
    neo domain ghost blog.example.com

Custom certificates

Upload your own TLS certificates. Useful for wildcard certs, internal CAs, or when using a cert from a specific provider.

neo domain my-app app.example.com --cert /path/to/fullchain.pem --key /path/to/privkey.pem

ssl:
  certificate: certs/fullchain.pem
  private_key: certs/privkey.pem

The certificate is uploaded to /etc/neo/certs/{app}/ on the server and loaded into Caddy.

Wildcard HTTPS New

Serve *.example.com from a single certificate. Neo configures Caddy for free wildcard certificates two ways — pick based on whether your subdomains are known up front or fully dynamic.

Option A — ACME DNS-01 (neo caddy dns)

Provisions a real Let's Encrypt wildcard certificate up front by proving domain ownership through a DNS record. Requires a DNS provider API token (currently Cloudflare). The token is read from a local environment variable and copied to the server as a root-only file — it is never typed interactively.

# Build a DNS-enabled Caddy, store the token, enable wildcard SSL
CLOUDFLARE_API_TOKEN=... neo --server prod caddy dns example.com --app my-app

# Bind the wildcard to an app afterwards (if --app was omitted)
neo domain my-app "*.example.com" --add

Option B — Guarded on-demand TLS (neo caddy ondemand)

For unbounded, dynamic tenant subdomains where you can't pre-list every hostname. Caddy issues a real certificate for each subdomain on its first request, gated by an ask URL your app controls — it must return 200 only for allowed hostnames.

neo --server prod caddy ondemand example.com --app my-app --replace-domains

Cloudflare Flexible SSL New

If your app sits behind Cloudflare in Flexible SSL mode — HTTPS between the browser and Cloudflare, plain HTTP from Cloudflare to your origin — serve the origin over HTTP while still telling the app it's on HTTPS. This prevents redirect loops without disabling TLS at the edge.

# Switch an existing app's origin route to Cloudflare Flexible mode
neo domain my-app --cloudflare-flexible

edge_https: true

Neo sets an HTTP-only origin route and injects the following headers so the app generates correct https:// URLs:

Deployment Versions New

Every deploy records the git commit it was built from, so “which code is running?” has an answer. Before this, an image tag carried only a timestamp: two deploys of different commits looked identical, and redeploying the same commit looked like a new version.

$ neo list
NAME               DOMAIN                 PORT   STATUS      VERSION
● shop             shop.example.com       8080   running     v1.4.2 (a1b2c3d)
● api              api.example.com        3000   running     9f01e2a *      # * = built from uncommitted changes

One app in detail

$ neo status shop

  shop  ●  on production

  Deployment
    Version      v1.4.2 (a1b2c3d)
    Commit       a1b2c3d4e5f6789...
    Branch       main
    Image        neo-shop:20260818-045536-a1b2c3d
    Deployed     2026-08-18T04:55:36Z  by alan@macbook
    Env digest   sha256:6fb787f3a6ad231e

The env digest fingerprints the environment the build ran with, so the same commit deployed twice with different configuration is distinguishable — otherwise “the code didn’t change, why did behaviour?” is unanswerable.

History

$ neo deploys shop

DEPLOYED             VERSION            BY
● just now           v1.4.2 (a1b2c3d)   alan@macbook
  3h ago             9f01e2a            ci@github-actions
  2d ago             v1.4.1 (7c4d2b1)   alan@macbook          image pruned

History lives on the server, in /etc/neo/deploys/<app>.jsonl, so everyone who deploys shares one record — your laptop, a colleague’s, and CI. It survives a fresh clone, and it is append-only, so two simultaneous deploys cannot overwrite each other’s entries. Entries marked image pruned are informational: Neo keeps only the last few images, so those builds are no longer on disk.

Inside the container

Each deploy injects variables describing itself, so the running container can identify its own build:

$ neo run shop -- printenv | grep NEO_GIT
NEO_GIT_COMMIT=a1b2c3d4e5f6789...
NEO_GIT_SHORT_COMMIT=a1b2c3d

env:
  SENTRY_RELEASE: "${NEO_GIT_COMMIT}"

Not using git?

Nothing requires it. A scaffolded template or a source tarball simply shows no version. In CI, where a shallow checkout often has no usable repository, Neo falls back to NEO_GIT_COMMIT, GITHUB_SHA or CI_COMMIT_SHA.

Checking a deploy from CI

# fail the job if the running commit isn't the one we just built
[ "$(neo status shop --json | jq -r .deployment.commit)" = "$GITHUB_SHA" ] || exit 1

Syncing State New

CLI commands like neo domain and neo env set update server state but don't modify .neo.yml. Use neo sync to write server state back to your config.

# Preview changes (dry run)
$ neo sync my-app --dry-run

  Syncing my-app: server → .neo.yml (dry run)

  ~ domain        example.com → my-app.1.2.3.4.sslip.io
  ~ https         false → true
  + env.NEW_VAR   hello

  3 change(s) detected. Run without --dry-run to apply.

# Apply changes
$ neo sync my-app

  Write 3 change(s) to .neo.yml? (y/n): y
  ✓ .neo.yml updated (3 changes)

What gets synced

Per-Environment Volumes

When you define volumes inside each environment block (instead of top-level), Neo creates separate Docker volumes per environment. This ensures production and staging never share a database or storage directory.

environments:
  production:
    env_file: .env.production
    volumes:
      data: /var/www/html/database
      storage: /var/www/html/storage
  staging:
    env_file: .env.staging
    volumes:
      data: /var/www/html/database
      storage: /var/www/html/storage

How naming works

Neo namespaces volumes by combining the app name and environment:

When to use which

Team Access (SSH Keys)

Give teammates their own access to a server with neo key — no shared passwords, no copying private key files, no GitHub. Everyone uses their own key; the admin authorizes or revokes each person individually.

Two roles

The only thing that passes between people is the teammate's public key — safe to send over Slack or email. Private keys never leave their owner's machine.

# [Teammate] Generate + print your public key to send to the admin
neo key show

# [Admin] Authorize a teammate's public key on the server
neo key add "ssh-ed25519 AAAAC3Nz... [email protected]"

# Target a specific server (otherwise uses the current one,
# or asks which when you have more than one configured)
neo key add --server production "ssh-ed25519 AAAAC3Nz... [email protected]"

# [Admin] List authorized keys (marks your own)
neo key list

# [Admin] Revoke a key by its number from the list
neo key remove 2

Step-by-step workflow

name: my-app
domain: app.example.com
server: root@your-server-ip   # full user@host — the @ skips local config

Attaching an existing server

neo attach registers a server that was already set up by someone else into your local config, so the dashboard, neo list, neo logs, and every other command work — without a --server flag on each call. Unlike neo init, it never installs Docker or Caddy and never overwrites the server's state, so it is safe to run against a live server with apps deployed.

# Add an already-initialized server to your local config
neo attach [email protected]

# Then everything works with no flag
neo list
neo logs my-app

Listing keys

neo key list shows every authorized key on the server with a number, and marks your own key with (you):

$ neo key list

  Authorized keys:

  #1   alan@macbook  (you)
  #2   [email protected]
  #3   ...Xk9mRpQ2aZ

  Remove a key with: neo key remove <number>

Revoking access

Run neo key remove <number> with the number from neo key list. Neo will not let you remove your own key — doing so would lock you out.

neo key remove 2   # revokes key #2

Domain Redirects New

Redirect any domain to another URL — no app, sidecar, or service required. Neo configures Caddy directly, so the redirect is live in seconds with auto-SSL provisioned for the source domain.

# 301 permanent redirect (default)
neo redirect add vxero.dev vxero.com

# 302 temporary redirect
neo redirect add old.api.com new.api.com --temporary

# List all active redirects
neo redirect list

# Remove a redirect
neo redirect remove vxero.dev

How it works

Example output

$ neo redirect add vxero.dev vxero.com

  ✓ Redirect active!

  From   vxero.dev
  To     https://vxero.com
  Type   301 permanent
  SSL    auto-provisioned by Caddy

  Paths are preserved: vxero.dev/blog → vxero.com/blog

Shared Services

A shared service is a database or cache container that runs at the server level, not inside any single app. Multiple apps can connect to the same instance — useful on small VMs where spinning up a separate database per app wastes hundreds of MB of RAM.

Supported types

Usage

# Create a shared service (runs once on the server)
neo service create mysql
neo service create postgres
neo service create redis

# See all services and their status
neo service list

# Show connection details anytime (host, port, user, password, URL)
neo service info mysql

# Other operations
neo service logs mysql
neo service start|stop|restart mysql
neo service remove mysql

Databases & Data

Neo can run databases in Docker via shared services or bundled templates. This works well for small projects, but production workloads with real user data should use managed database services.

Three approaches

When to use what

Why managed databases for production

Docker databases on a single VPS have real limitations that managed services solve:

Recommended managed providers

Connecting to an external database

Point your app at a managed database by setting the connection string:

# Set database URL (app restarts automatically)
neo env set my-app DATABASE_URL=postgres://user:[email protected]/mydb

# Or set individual vars
neo env set my-app \
  DB_HOST=db.neon.tech \
  DB_PORT=5432 \
  DB_DATABASE=mydb \
  DB_USERNAME=user \
  DB_PASSWORD=secret

env:
  DB_CONNECTION: pgsql
env_file: .env.production  # contains DATABASE_URL (not committed to git)

Backing up Docker databases

If you do run databases in Docker, supplement Neo's volume backups with database-native dumps:

# MySQL dump
neo ssh
docker exec svc-mysql mysqldump -u root -p'$PASS' --all-databases > /var/backups/mysql-$(date +%F).sql

# PostgreSQL dump
docker exec svc-postgres pg_dumpall -U postgres > /var/backups/pg-$(date +%F).sql

# Download to your laptop
scp root@your-server:/var/backups/mysql-2026-03-23.sql ./backups/

Server Management

# List servers
neo servers

# Switch active server
neo use production

# Remove a server from config
neo servers remove old-server

# SSH into server
neo ssh

# Target a specific server for any command
neo list --server staging

Firewall (CrowdSec)

Neo ships an optional firewall powered by CrowdSec — a free, open-source intrusion-prevention engine. It watches your logs, auto-bans brute-force attackers with an nftables bouncer, and pulls in a community-maintained blocklist of known-malicious IPs. Everything runs on your server; nothing is sent to Neo.

Install

# Install CrowdSec + the nftables bouncer on the active server
neo firewall install

Install is idempotent — running it again on an already-protected server is a no-op. Neo records the firewall state in /etc/neo/state.json.

Manage decisions

# Service status + active decision count
neo firewall status

# List every active decision (ban)
neo firewall list

# Manually ban / unban an IP or range
neo firewall block 203.0.113.10
neo firewall unblock 203.0.113.10

# Update the engine, bouncer, and community blocklists
neo firewall update

Stealth Mode

Stealth mode hides your server from IP-based discovery. When enabled, Neo removes Caddy's catch-all welcome page, so direct requests to the server's IP get no response — only your configured domains serve traffic. This stops scanners from fingerprinting the box.

# Toggle stealth on (removes the IP welcome page)
neo stealth

# Run again to toggle it back off (restores the welcome page)
neo stealth

CLI Reference

Global flags

Server Requirements

What Neo installs on your server

When you run neo init, Neo touches exactly two things on your VM:

That's it. Neo does not install PHP, Python, Go, Node.js, Ruby, Java, or any other language runtime. It does not install database clients, build tools, package managers, or any other system software.

What Neo is not

Neo is deliberately focused. Before adopting it, it's worth being clear about what it does not do.

Architecture

Neo is a single Go binary that runs on your local machine. It has no server-side component — everything happens over SSH.

Container naming

Docker network

All containers join the neo Docker network. Containers reference each other by name (e.g. svc-mysql:3306).

Volume naming

Volumes are prefixed with the app name: {app}-{volume}. For example, an app named ghost with a volume content creates ghost-content.