Skip to content

Deploy OpenCircle

Deploy to a Linux server

Prepare DNS, SSH, Docker, firewall boundaries, and automatic HTTPS for an OpenCircle VPS.

This is the persistent self-hosted path: one public DNS name, one SSH-reachable Linux machine, and one Compose lifecycle owned by your circle. Any VPS provider can work; OpenCircle has no provider-specific driver.

Decide the public names first

The generated reverse proxy serves two HTTPS sites: your chosen domain routes to the OpenCircle Server, and auth.<domain> routes to the identity service. Point both at A records for the VPS (and AAAA only if it truly has IPv6), then wait for public resolvers to agree before continuing.

Terminal

dig +short A circle.example.org
dig +short A auth.circle.example.org

Prepare the host and its firewall

Host prerequisites

Use a maintained Linux distribution with Docker Engine and the Compose plugin, a dedicated noninteractive SSH key already authorized for an operator account, and an owner-writable deployment directory outside any web root.

On the host

sudo install -d -o operator -g operator -m 700 /srv/opencircle

Firewall boundary

PortSourcePurpose
SSH portNamed administrator networks onlyOpenCircle lifecycle operations
TCP 80Public InternetHTTP redirect and certificate validation
TCP 443Public InternetOpenCircle HTTPS and certificate validation

Block every other inbound port, including the direct Server, identity-service, and database ports. Enforce this at the VPS or upstream firewall, since container-published ports can bypass a host-only firewall rule.

Pin the SSH identity and create a profile

Compare the presented host-key fingerprint against one obtained through a trusted channel before saving it, and test the exact noninteractive path OpenCircle will use.

Terminal

ssh-keyscan -t ed25519 -H circle.example.org > /tmp/opencircle-vps.known-hosts
ssh-keygen -lf /tmp/opencircle-vps.known-hosts

Terminal

opencircle profile add circle-server \
  --transport=remote --lifecycle=compose \
  --instance-id=circle \
  --ssh-host=circle.example.org \
  --ssh-user=operator \
  --ssh-identity-file="$HOME/.ssh/opencircle_vps_operator" \
  --remote-path=/srv/opencircle \
  --domain=circle.example.org \
  --base-url=https://circle.example.org \
  --https=letsencrypt \
  --acme-email=operator@example.org \
  --yes

For pre-production testing, create a separate profile with --acme-staging so failed experiments do not consume production certificate limits; staging certificates are not browser-trusted.

Deploy and verify

Terminal

opencircle deploy --profile circle-server --owner-mode claim --finish guide

Check the hostname and certificate before entering the one-time claim link. Require owner-bound, then verify routing and TLS from a normal client network:

Terminal

opencircle status --profile circle-server
curl --fail --silent --show-error https://circle.example.org/health
openssl s_client -connect circle.example.org:443 \
  -servername circle.example.org </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Troubleshoot certificates and plan renewal

If HTTPS is not ready, do not recreate the Server. Recheck public DNS for both names, confirm the firewall allows public 80/443 with no conflicting process already bound to them, and inspect the proxy's managed logs. Once DNS, firewall, and port conflicts are fixed, leave the proxy running; it retries with backoff.

The reverse proxy renews certificates automatically as long as its storage volume stays writable and both DNS names keep pointing at the host. Deleting that storage forces new issuance and can trigger provider rate limits. Day-two release changes belong to opencircle upgrade --profile circle-server, not to deploy.