ZenHost

Why it exists

I started ZenHost because deploying and managing ordinary applications still involves too many unrelated tools and too much hidden knowledge. If you want to host a web application today, you either pay a premium for a PaaS that completely abstracts the server away, or you rent a VPS and spend a weekend configuring Nginx, Docker, SSL certificates, and CI/CD pipelines.

I wanted something in the middle: a platform that automates the deployment and routing, but doesn’t try to pretend the underlying server doesn’t exist.

What it is

ZenHost is a hosting platform designed to take a git repository and turn it into a running application with a database, SSL, and automated builds, while preserving understandable infrastructure. It’s built for developers who want the convenience of a modern PaaS without losing access to the raw underlying systems when things go wrong.

The first version

The first version was incredibly naive. It was essentially a Go daemon that listened for GitHub webhooks, cloned the repository, built a Docker image, and ran it. It bound the container directly to a host port and updated an Nginx configuration file before reloading the server.

It worked for one person. It was fast, and it solved my immediate problem of wanting to git push to deploy without writing GitHub Actions for every small project.

What became difficult

The simplicity broke down immediately once multiple tenants were introduced. Port conflicts became a constant issue. Everyone wanted their Node.js app to run on port 3000.

Tenant isolation, runtime management, and deployment state suddenly became serious engineering problems. I had to rip out the direct port binding and implement a dynamic reverse proxy that communicated with an internal bridge network. I had to learn how to securely stream build logs to a frontend in real-time without overwhelming the browser or the server.

What I chose not to hide

The defining product decision of ZenHost is that it preserves understandable infrastructure. Instead of wrapping Docker in three layers of proprietary configuration, ZenHost simply runs standard Docker containers. If the platform interface fails, a user with SSH access can still run docker ps and see exactly what is happening.

We manage the complexity of routing and builds, but we don’t invent new concepts where standard Linux and container primitives already exist.

Where it is now

The platform is currently operating at a modest scale with a handful of design partners. The core deployment pipeline is stable, the dynamic reverse proxy handles traffic efficiently, and the basic tenant isolation holds up well against normal usage. We are discovering the limits of running a multi-tenant platform on a single host machine.

What comes next

The next few goals are focused on infrastructure. Moving from a single-node architecture to a distributed setup without inheriting the full complexity of Kubernetes is the primary engineering challenge. On the product side, we are refining the logging interface and improving the speed of the build pipeline.