One developer. The whole workflow.

Your app.
Your server.
Your way to ship.

Build, deploy, and operate your apps from the terminal. Solo connects your local workflow to your own server with SSH, container deployment, and visibility into what is running.

Deploy your first app Explore the docs

Start with one Ubuntu 22.04 LTS server. Keep the configuration with your code. Add more when you need it.

solo / runtime snapshot
# Captured output · selected columns
$ solo ps
APP          RELEASE        STATE    MEMORY
----------------------------------------------------
proxy        -              running  33.92MiB (3.57%)
solo-docs    26-11-08-1211  running  2.488MiB (0.26%)
swift-hello  26-11-08-1202  running  9.195MiB (0.97%)
3 containers
Build locallyDeploy over SSHInspect live state

Actual Solo output, with selected columns shown. IDs and the local prompt are omitted. See the full example ↗

Small setup. Clear boundaries.Swift CLISSH transportDocker runtimesolo-proxy ingress

Your deployment toolkit

Ship it. Run it.
Stay close to it.

When you are the developer and the operator, the useful tools should be close at hand.

01 / BUILD

Use the tools you know

Native Swift container builds, or your own image-building command. Review the artifact before it goes anywhere.

02 / DEPLOY

Make the switch deliberately

New replicas pass readiness checks before receiving requests. The proxy drains old requests and observes the new backend.

03 / OPERATE

Know what is running

App containers, logs, TLS state, and deployment history are a command away. Inspect a drift plan before applying changes.

04 / SERVER

Give your app a home

Prepare Ubuntu 22.04 with Docker, the proxy, UFW, and fail2ban. Keep server setup close to your deployment workflow.

05 / VISIBILITY

Keep an eye on the whole server

Prometheus and Grafana bring proxy, host, and container metrics together. Monitoring endpoints stay private by default.

06 / ACCESS

Keep your admin path private

Move SSH to Tailscale after verifying connectivity. Reach Grafana through a tunnel or private Tailscale Serve.

Understand the moving parts

A direct route from
your machine to your app.

The local CLI coordinates builds and deployments over SSH. On your server, Docker runs the containers and solo-proxy routes requests to healthy replicas.

Proxy management uses a private Unix socket. Public traffic enters on ports 80 and 443. You can inspect the pieces you depend on.

Explore the architecture
The single-server setup
On your machineSolo CLI

solo.yml · builds · local state

↓ SSH · private management socket
On your serverDocker + solo-proxy

HTTPS ingress → healthy app replicas

Readiness checksTraffic drainingMetrics

A workflow you can follow

One configuration.
Explicit next steps.

Build and deploy are separate decisions. Know which image you are sending and where it will run.

01

Describe the app and server

solo init --interactive helps create your configuration. Choose the builder, domain, and service port, then review the result.

02

Build an artifact

Use a native Swift container build or an explicit image command. Native Swift builds can use a managed registry; other local images can travel as SSH tarballs.

03

Deploy, then inspect

Review the selected build. Solo delivers it and asks the proxy to check readiness before switching traffic. Follow with logs, status, and a drift check.

solo.yml / native Swift package example
project: my-project
servers:
  - host: 203.0.113.10
    domain: example.com

services:
  - name: api
    port: 8080
    replicas: 2
    builder:
      type: swiftPackageContainer
      sdk: x86_64-swift-linux-musl
      product: MyServer
    proxy:
      host: api.example.com
      healthcheck:
        path: /up

Requires swift-container-plugin, a matching Linux SDK, and HTTP 200 on /up. Static sites use an explicit builder and a / health check.

After the first deploy

The questions do not
stop at “it is live.”

Check what changed, find a failing health check, or open your private dashboards. The docs are organized around the next thing you need to do.

What is running?solo ps ↗ What is the app saying?solo logs ↗ Does live state match?solo reconcile ↗ How do I reach monitoring?private access ↗ Why did this deploy fail?troubleshooting ↗

Current capabilities and limits.

Solo is evolving. Provisioning supports Ubuntu 22.04 LTS. The default Dockerfile builder is unfinished, so the quickstart uses an explicit command builder. Watchdog rollback covers the observation window; historical release rollback remains a gap.

Optional multi-server coordination includes certificate synchronization, centralized metrics, and manual TLS leader promotion. It does not provide automatic leader election.

Current scope · Comparison and gap tracker

Start with one app.
Make the server yours.

A static site is a good first deployment.

Open the quickstart