Building mop_dev: A High-Performance Rust Infrastructure for Unconventional Web Apps
As a Rust web artisan, I demand more than just standard boilerplate from my infrastructure. I need a meticulously crafted foundation capable of hosting high-end, complex, and unconventional web applications without sacrificing an ounce of speed or reliability. Enter mop_dev—my custom-built, production-grade infrastructure designed from the ground up to guarantee excellent uptimes and lightning-fast execution.
This article pulls back the curtain on the architecture, custom tooling, and deployment pipelines that power the mop_dev ecosystem.
---
1. The Hub & Spoke Architecture
At the core of the mop_dev infrastructure is a robust Hub & Spoke model, operating entirely on a hardened Debian 13 server. Rather than deploying fragmented, isolated applications, the architecture routes everything through a central nervous system.
The Hub (mop_dev)
The Hub acts as the Identity Provider (IDP) and the primary reverse proxy. Sitting directly behind Cloudflare (which handles DNS, strict SSL termination, and WAF), the Hub listens on port 443. It is a highly optimized Rust Axum backend paired with a Yew WASM frontend.
The Hub utilizes a custom HostSwitchService pattern for O(1) routing. It dynamically directs traffic based on the Host header by checking the proxy_routes database table. Whether it's the primary static routes (mop.dev, auth.mop.dev, cdn.mop.dev) or dynamic tenant domains, the Hub handles the orchestration seamlessly.
The Spokes (Tenant Applications)
The spoke applications are the individual, specialized web apps running on dedicated local ports (e.g., 3001 to 3008). They are entirely shielded from the public internet, binding only to 127.0.0.1.
- womed_it: Healthcare platform (Port 3001)
- mop_template: Baseline for new applications (Port 3003)
- cuic_it: B2B cargo-bike logistics, also served on its own domain cuic.it (Port 3006)
- mop_timistic: CBT-based mental wellbeing app (Port 3007)
- factorio_index: LLM agent benchmark platform (Port 3008)
Because these spokes communicate exclusively through the Hub router, managing cross-origin resource sharing (CORS), unified authentication, and secure data flow becomes incredibly streamlined.
---
2. Zero-Downtime Deployments
Uptime is non-negotiable for high-end web applications. To ensure seamless transitions during updates, the mop_dev infrastructure utilizes an atomic symlink swap deployment pipeline orchestrated by GitHub Actions.
When code is pushed, the CI/CD pipeline runs rigorous formatting, linting (cargo clippy), and testing. Once the artifact is built and database migrations are verified, the deployment script executes a zero-downtime swap.
Bash
# Zero-Downtime Deployment via Atomic Symlink Swap
# 1. The old state points to the current active release
# /opt/mop/current -> /opt/mop/releases/0.1.0-abc1234
# 2. Create a new symlink pointing to the newly compiled release
sudo ln -sfn /opt/mop/releases/0.1.0-def5678 /opt/mop/current.new
# 3. Atomically overwrite the existing 'current' symlink with the new one
sudo mv -Tf /opt/mop/current.new /opt/mop/current
# 4. Gracefully restart the systemd service
sudo systemctl restart mop
If the post-deployment health check fails, the system automatically rolls back by instantly repointing the symlink to the previous version directory (PREV_RELEASE). This guarantees that a bad build never takes down the live environment.
---
3. The Developer Experience: Custom Tooling
A true artisan builds their own tools. The mop_dev ecosystem relies on a bespoke suite of utilities that drastically reduce friction during the development lifecycle.
The mop_cli DevOps Tool
Written in Rust, the MoP CLI is the command center for server configuration, secret management, Cloudflare DNS provisioning, and even internationalization (i18n) harvesting via AST extraction. It allows me to spin up new GitHub Action runners, synchronize environment variables, and enforce security policies directly from the terminal.
PGLite Unified Bridge for Local Testing
To ensure local development perfectly mirrors production without the overhead of heavy Dockerized databases, the workspace utilizes PGLite (PostgreSQL in WASM).
A custom Node.js TCP bridge (pglite_bridge.js) orchestrates isolated database instances for every application. Each spoke app gets its own lightweight, locally mapped port (e.g., 5438 for mop_dev). This allows for incredibly fast, memory-backed testing environments that require zero complex setup.
The MCP Orchestrator
The infrastructure is fully integrated with a Model Context Protocol (MCP) server (mop_mcp). This allows my AI coding assistants to seamlessly read production logs via SSH, execute SQL queries against the live database, run Cypress E2E tests, and simulate full deployments locally before pushing a single commit.
---
4. Uncompromising Security and Performance
Every layer of mop_dev is built defensively:
- Systemd Hardening: Services are isolated using strict directives like NoNewPrivileges=yes, PrivateTmp=yes, and ProtectSystem=strict.
- Database Isolation: The production PostgreSQL 16 database binds strictly to localhost. Each tenant application connects using a dedicated user with minimal schema privileges.
- Strict Firewalling: The Hetzner box utilizes UFW configured to allow HTTP/HTTPS traffic only from verified Cloudflare IP ranges. All other traffic is silently dropped.
- Unified Master Workspace: All 27 internal crates share standardized dependencies (like axum 0.8.1 and tokio 1.42) compiled from a root Cargo.toml. This ensures binary sizes remain small, compile times are optimized, and memory overhead is strictly controlled.
mop_dev isn't just a place to host code; it is a meticulously engineered environment that allows me to focus purely on the art of writing high-performance Rust applications, knowing the infrastructure will handle the rest with absolute reliability.
Would you like me to generate a specific technical diagram snippet (like a Mermaid.js chart) to replace the image placeholders, or adjust the tone of any specific section before you publish it?