Building a Self-Hosted Netlify/Vercel Alternative in Rust: An Architectural Crossroad

Archit — Sun, 19 Oct 2025 11:09:36 +0000

Why I'm Building My Own Self-Hosted Deployment Platform (And Why You Might Want One Too)

Hey fellow developers and self-hosting enthusiasts,

If you're anything like me, you've probably felt the pinch of monthly subscription creep for simple deployments. Or maybe you've grown weary of vendor lock-in and the opaque nature of cloud infrastructure. And let's not even start on paying for bandwidth when you've already got a competent server sitting idle.

That's why I've embarked on a mission: to build a self-hosted deployment platform – a bit like Netlify or Vercel, but entirely under your control, running on your own hardware. My goal is to create a robust, high-performance, and ultimately free alternative that empowers developers to own their infrastructure truly.

Why Rust? The Core of the Decision

Choosing the right technology stack for a project like this is crucial. I decided to build the core engine in Rust, and for good reason:

Performance: Deploying applications efficiently and handling many concurrent requests demands speed. Rust delivers near-C/C++ performance.
Memory Safety: When managing multiple build processes, webhooks, and proxying, memory leaks or segmentation faults can be catastrophic. Rust's ownership model provides strong guarantees against these issues.
Concurrency: Rust's excellent async story makes it ideal for handling high-throughput I/O operations central to a deployment platform.

What's Currently Working (The MVP in Progress)

I'm deep into development, and the Minimum Viable Product (MVP) is taking shape. Here's what's already functional:

Static Site Deployment from Git: Push to your main branch, and the platform automatically triggers a rebuild and deployment.
Automatic SSL/TLS: Integrated Let's Encrypt support ensures all your deployed sites are secure out of the box.
Simple Dashboard: A basic UI to manage your deployments and attached domains.
Technical Architecture: The platform is designed as a single, lightweight Rust binary. It handles everything: receiving Git webhooks, orchestrating the build process (using isolated Docker containers), and serving the content.

What's Next on the Roadmap (4 Weeks to Launch)

The plan for the initial launch is ambitious but focused:

Dockerfile-Based Deployments: Extending support for dynamic applications (Node.js, Python, Go, etc.) using custom Dockerfiles.
Custom Build Commands & Environment Variables: Granular control over the build process for complex projects.
Zero-Downtime Deployment Strategies: Ensuring seamless updates without any service interruptions.

I Need Your Brainpower: Critical Architectural Decisions

This is where you come in! As I finalize the architecture, I've hit a crossroads, and I believe the collective wisdom of the dev team to community will be invaluable.

My Big Question: Integrated vs. External Reverse Proxy?

For handling the final traffic routing and domain mapping from user requests to the deployed applications, which design makes more sense for a self-hosted environment like this?

Integrated Proxy: Keep the entire reverse proxy logic inside the main Rust binary.
- Pros: Simpler deployment (one single binary to run), potentially maximum performance tuning, full control.
- Cons: Requires re-implementing battle-tested features (like advanced caching, request buffering) that dedicated tools already excel at.
External Proxy: Have the Rust binary generate configuration files for a dedicated, external reverse proxy (like Traefik, Caddy, or Nginx) and then trigger a reload for that service.
- Pros: Leverages incredibly robust and feature-rich external tools, separates concerns cleanly, and potentially better observability via external proxy logs.
- Cons: Adds another service dependency, slightly more complex initial setup for the user (requires installing and configuring the proxy too).

What are your thoughts on this, especially considering factors like stability, ease of logging, performance, and overall maintainability in a self-hosted context?

Let's Build This Together!

Your feedback on the proxy design, and any other "must-have" features you'd expect from a self-hosted deployment platform, would be incredibly helpful as I push towards launch.

Want to check out the code or contribute?
You can follow the project's progress on GitHub: https://github.com/ArchitTheGreat/https_server

Leave your thoughts in the comments below! I'm genuinely excited to hear what you think.