Anchor - Personal Server Management

Project Story

Inspiration

Cloud platforms like AWS and Azure are built for companies that can afford a dedicated DevOps team — but most small businesses, freelancers, and dev agencies just have a single cheap VPS or an old machine sitting under a desk. We kept seeing the same pattern: people running production apps off servers they were genuinely afraid to touch, because one wrong command could take everything down with no way back.

At the same time, tools like Coolify and CapRover had already proven that self-hosted "mini-clouds" work — but they're still built for people comfortable with SSH keys, reverse proxies, and Docker internals. We wanted something a small business owner could trust without knowing what any of those words mean.

That gap — powerful infrastructure, zero technical friction — is what Anchor is built to close.

What it does

Anchor connects to any Linux server — a VPS, a rented box, or hardware you already own — and turns it into a self-managing deployment platform:

Deploy in one click from a Git repo or Docker image, with ready-made templates for common stacks
Automatic HTTPS on your own domain, with zero certificate management
Self-healing — apps restart automatically if they crash
Daily backups with one-click restore, so "I broke something" is never a crisis
Plain-English alerts — instead of a wall of graphs, you're told exactly what went wrong and when

The dashboard is the only thing a user ever touches. Everything else — Docker, TLS, backup scheduling, health checks — runs invisibly on the server itself.

How we built it

The system is split into two halves that talk to each other:

The agent — a small Go binary installed on the user's server with a single command. It wraps Docker for running containers, embeds Caddy for automatic reverse proxying and HTTPS, and shells out to restic for reliable, storage-agnostic backups. Go was chosen specifically because it compiles to a single dependency-free binary that runs identically on a $5 VPS or a Raspberry Pi.
The control plane — a Go backend with a PostgreSQL database, communicating with agents over authenticated WebSocket connections for real-time logs and health data. The frontend is a Next.js + TypeScript dashboard where users connect servers, deploy apps, and manage backups — no command line involved at any point.

We deliberately avoided building anything already solved well: no custom hypervisor, no custom container runtime, no custom TLS stack. The goal was to be the simplest possible layer on top of proven open-source tools, not to reinvent them.

Challenges we ran into

Deciding what not to build. The instinct was to add multi-server orchestration, autoscaling, and clustering early — but that's exactly what makes existing tools intimidating. Staying disciplined about single-server, single-purpose simplicity was harder than adding features.
Making failure states friendly. Translating raw container exit codes and system signals ("OOMKilled", "exit 137") into a sentence a non-technical user actually understands took more iteration than the deploy flow itself.
Keeping the agent lightweight. Since the agent runs alongside the user's actual application on the same small server, every extra megabyte of memory or CPU cycle competes directly with the app it's meant to be protecting.

What we learned

The hard problem was never the infrastructure — Docker, Caddy, and restic already solve that reliably. The hard problem was trust: making someone who's afraid of their own server feel safe enough to click "deploy" and mean it. Every design decision, from templates to backup buttons to alert wording, came back to that single goal.