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
| Port | Source | Purpose |
|---|---|---|
| SSH port | Named administrator networks only | OpenCircle lifecycle operations |
| TCP 80 | Public Internet | HTTP redirect and certificate validation |
| TCP 443 | Public Internet | OpenCircle 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.