Personal Self-Hosted Deployment Platform

I moved off Vercel Pro and built a self-hosted deployment setup on a Hetzner VPS using Dokploy. The goal was to own the full deployment pipeline end-to-end (apps, domains, SSL, databases, automation, and AI services) while keeping deployments repeatable and cost predictable.

Why I Built This (Reasoning)

Managed platforms like Vercel optimize for speed and convenience, but they come with tradeoffs once you move beyond a single frontend: costs grow when you need always-on backends, databases, and background jobs; less control over networking, storage, and system-level behavior; and it is harder to host multiple services (automation + DB + AI inference) in one place.

I wanted a setup where I can run multiple services on one VPS, keep cost stable and predictable, control networking, storage, secrets, and deployments end-to-end, and get hands-on practice operating systems the way real teams do in production.

What I Built

A small "personal PaaS" running on a single VPS. It consists of a compute layer (Hetzner VPS), deployment layer (Dokploy), runtime (Docker containers per service), data layer (PostgreSQL, Redis, MongoDB, ClickHouse for experimentation), an AI service (Ollama via HTTP API), and self-hosted documentation tools for my personal projects and my volunteer work at Young Professionals Canada. It also includes my own custom applications running behind custom subdomains and SSL HTTPS routing.

Cost and Infrastructure (Hetzner VPS)

- Specs: 3 vCPU, 4 GB RAM, 80 GB SSD.

- Pricing: $9.99 / month (Current usage cost shown: $7.37)

- Location: Ashburn, VA (us-east)

- Network and Security: Hetzner Firewall enabled with restricted inbound rules.

Next Steps (Planned Deployments)

I’m continuing this as an infrastructure learning track. The next phase is focused on running real distributed patterns instead of a single-host setup.

Docker Swarm cluster

Build a small Swarm cluster (manager + workers), practice rolling deploys, service discovery, overlay networking, and failover behavior, and re-run the same platform services under Swarm to see what breaks and why.

Database replication and sharding experiments

Replication: learn availability tradeoffs and failure modes (promotion, split brain risk, recovery). Sharding: learn partitioning tradeoffs (routing, hotspots, rebalancing, operational complexity). The goal is not "production grade sharding" on day one, but learning the real operational pain points.

Deploying IssueSight on Swarm (Distributed architecture validation)

I’ll deploy IssueSight on Swarm to validate the system under real distributed conditions since it is a distributed event-driven system. Swarm is the right next step because it forces real questions: can services be replicated safely, what state must be single vs multi-writer, what fails when a replica dies mid-task, and how to prevent duplicate processing.