Forem: DAVID VIEJO

How I Use AI to Build a 55-Crate Rust Project (Honestly)

DAVID VIEJO — Fri, 20 Mar 2026 06:50:57 +0000

I build Temps alone. The codebase is 55 Rust crates. That's a lot of surface area for one person. So yes, I use AI assistance heavily. Claude, mostly.

I want to be specific about how I use it, because the honest answer is more nuanced than "AI writes my code" or "I write everything myself."

What AI is actually good at

Boilerplate. Rust has a lot of it. Implementing a trait for a new type means writing the same three methods with the same signature patterns I've written fifty times. I'll describe what I need and let Claude draft the implementation. I read every line before it goes in, but the drafting is fast.

Tests. Writing unit tests is often more tedious than writing the code being tested. AI drafts test cases quickly. I review them for completeness, add the edge cases it missed (there are always edge cases it missed), and move on.

Documentation. Rust has rustdoc, and public APIs need doc comments. Describing what a function does in a comment is the kind of task where AI is faster than I am and the output is usually as good or better.

Debugging known error classes. If I have a borrow checker error I've seen before, I'll paste it in and let Claude explain what's happening. This is faster than re-deriving the explanation from first principles every time.

Translation between representations. I have a Postgres schema and I want the corresponding Sea-ORM entity structs. That's mechanical translation. AI handles it in seconds. I verify the output and check the types.

What AI is not good at

Architecture decisions. I've tried asking Claude to help me decide how to structure a new subsystem and the answers are plausible but shallow. They don't account for the specific constraints of my codebase's design, the things I know from having built it over two years that aren't captured in any single context window.

Debugging race conditions. When something is timing-dependent, when a test fails 1 in 20 runs, when a deployment works on the third retry but not the first, AI suggestions are often confident and wrong. These bugs require understanding the system's actual runtime behavior, not its code structure.

Knowing when to say no. AI will implement almost any feature I describe if I frame the request confidently. It rarely pushes back with "this is the wrong approach" or "this will create a problem in three months." That skepticism is something I have to supply myself.

Subtle Rust lifetime issues. Straightforward borrow checker errors are fine. But the ones that involve async lifetimes, shared mutable state across task boundaries, or complex interaction between the proxy and the deployment engine — those require careful human reasoning. AI gets them wrong often enough that I've learned to treat its suggestions as a starting point, not an answer.

How I've changed how I work

The biggest shift is that I've stopped writing first drafts of boilerplate myself. I used to start every new module by typing from scratch. Now I describe what I want in a comment and let Claude draft the structure, then I revise from there.

This sounds minor, but it changed my relationship with tedious tasks. The parts of coding I used to procrastinate because they were boring are now the fastest parts. The cognitive overhead of starting a new file went to nearly zero.

What it means is that my attention is available for the hard parts. Designing the state machine for a new deployment feature. Thinking through the failure modes. Deciding what to leave out. That's where I spend my time now.

The parts I want to get better

Prompt engineering for Rust codebases is still somewhat rough. I've gotten better at providing context (I include relevant type signatures, trait bounds, and architectural constraints in my prompts) but there's still a lot of back-and-forth on anything non-trivial.

I'd like better integration with the actual codebase — asking questions about my specific code rather than generic Rust patterns. That's getting better. But it's not there yet.

Honest assessment

AI made me probably 30% faster overall. Not 10x, not 2x. 30%. The gains are concentrated in the boring parts, which means the hard parts (the architecture, the edge cases, the debugging) are still slow. But they're the same speed they would have been without AI. The tedium tax came down.

For a solo developer building something this large, 30% faster is the difference between shipping and not shipping.

Why We Chose Rust for a Deployment Platform

DAVID VIEJO — Fri, 20 Mar 2026 06:50:54 +0000

Every Rust project eventually publishes a post about memory safety. This isn't going to be that post. Memory safety is real, and it matters, but it's not why we chose Rust for a deployment platform. There are better reasons, and they're more concrete.

The single binary problem

Deployment tools have a distribution problem. Install a typical self-hosted PaaS and you're pulling Docker images, Node.js runtimes, PHP scripts, and a handful of dependencies that need to stay in sync. Something breaks in an update, and you're debugging which layer of the stack caused it.

Temps ships as one binary. No runtime, no interpreter, no package manager to satisfy. Download a ~30MB file and you're done. That binary contains the proxy, the deployment engine, the analytics pipeline, the error tracking backend, the uptime monitor, and the AI gateway.

Rust makes this possible. The compiler links everything statically. You cross-compile for x86_64-unknown-linux-gnu or aarch64-unknown-linux-gnu on a Mac, upload the artifact, and it runs. No "please install libssl-dev" errors on the target server.

Go can do this too, but Go has a garbage collector.

GC pauses are the wrong tradeoff for a proxy

The proxy is the most latency-sensitive piece of the platform. Every HTTP request passes through it. When you're routing hundreds of concurrent connections and doing TLS termination, a pause of even 10ms is visible to users.

Go's garbage collector has gotten excellent. Modern Go applications see GC pauses in the 1-2ms range under normal conditions. But "normal conditions" is the problem. Under memory pressure, during a traffic spike, when large objects are being collected, pauses creep up. And a deployment platform sees traffic spikes by definition, because deployments themselves generate bursty internal traffic.

Rust has no garbage collector. Memory is freed deterministically when the owning variable goes out of scope. The proxy's latency profile under load is the same as its latency profile at idle. That predictability matters when you're routing traffic for a production application.

50MB for an entire platform

The full Temps process, handling active deployments, collecting analytics, running the proxy, and polling for uptime, idles at roughly 50MB of RAM.

Compare that to what you'd need to assemble the equivalent toolkit:

A Node.js analytics server: 200-400MB resident
A Go-based proxy (Traefik): 50-100MB
A Python error tracking backend: 300-500MB
A monitoring daemon: 50-100MB

Stack them together and you're at 600MB-plus before your first application is even deployed. On a small VPS with 2GB RAM, that's 30% of your available memory gone to tooling.

Rust's compiled code is dense. There's no VM overhead, no JIT warm-up, no per-request interpreter work. The binary does exactly what the source code says, at hardware speed.

Cross-compilation without tears

Temps runs on Hetzner ARM instances, on x86 bare metal, on Raspberry Pi clusters, and on Apple Silicon development machines (for local testing). Supporting that matrix without Rust would mean maintaining separate builds, separate runtimes, or a virtualization layer.

With Rust, cross-compilation is a compile flag. The CI pipeline produces four target binaries from the same source: x86_64-linux-gnu, aarch64-linux-gnu, x86_64-darwin, and aarch64-darwin. The install script picks the right one. No containers, no QEMU, no emulation layer needed on the target.

The proxy handles thousands of connections without struggling

Temps uses Pingora (Cloudflare's proxy engine, also written in Rust) for all traffic routing. Pingora was written because nginx's architecture doesn't handle connection reuse well at scale. Cloudflare processes trillions of requests per day through it.

Pingora uses async Rust (tokio) for its I/O model. Each worker thread handles thousands of concurrent connections through non-blocking I/O, without the per-connection thread overhead of nginx's workers. The result is consistent throughput under load, not throughput that degrades as connection count climbs.

For a platform that's doing zero-downtime deploys (spinning up new containers, running health checks, swapping routes under live traffic), this matters. The proxy doesn't buckle when deployment events create a burst of internal routing work.

A practical note

None of this means Rust is the right tool for every problem. The landing page is Next.js. Infrastructure scripts are bash. Rust earns its complexity budget specifically where you need compile-time guarantees, low overhead, and predictable runtime behavior. The key question when evaluating Rust for a project is whether the proxy and concurrency requirements justify the learning curve and compile times. For a deployment platform's core, the answer was yes. For a lot of other projects, it wouldn't be.

Session Replay: What It Is, How It Works, and When You Need It

DAVID VIEJO — Fri, 20 Mar 2026 06:50:51 +0000

Session replay records what users actually do on your site: mouse movements, clicks, scrolls, keypresses, and every DOM mutation. Play it back and you're watching a user's experience as they lived it.

It sounds invasive. It kind of is. That tension is worth understanding before you pick a tool.

How session replay actually works

Almost every session replay tool in existence — FullStory, Hotjar, LogRocket, PostHog Replay, Microsoft Clarity, and most self-hosted options — is built on the same foundation: rrweb.

rrweb (record and replay the web) is an open-source library that works in two steps. First, it takes a full snapshot of the DOM at the start of a session. Then it records every subsequent mutation as a compact, serialized diff. Scroll positions, CSS changes, added or removed elements — every change gets timestamped and appended to the recording stream.

On replay, rrweb reconstructs the DOM from the initial snapshot and replays the mutations in order, synced to a virtual timeline. What you see isn't a video file. It's a reconstructed DOM — which is why replays can be paused, scrubbed, and inspected as live HTML.

The practical implications of this architecture matter:

Storage is small. A typical 5-minute session compresses to 100-500KB. Much cheaper to store than video.

What gets captured is everything rendered. rrweb captures the full DOM, which means user-visible text, form fields, error messages, and anything else on the page. Including sensitive content that you didn't intend to capture.

Network requests are captured separately. Most tools also let you record XHR/fetch requests alongside the DOM replay, which helps correlate user actions with API calls.

The privacy problem is real

In 2017, Princeton researchers found that session replay scripts on popular sites were capturing credit card numbers and passwords in plain text. The mechanism was simple: rrweb captures form field values by default. If your input isn't masked, the content gets recorded.

Most tools have added automatic masking heuristics since then — detecting fields with type="password", matching patterns for card numbers, etc. But the fundamental issue remains: you're serializing the entire rendered DOM and shipping it somewhere. Unless you explicitly audit what gets captured, you can leak sensitive data.

The tooling has three approaches to this:

Input masking: Replace field values with placeholder characters (*****). All major tools support this. It's on by default for password fields; for other sensitive fields, you have to configure it.

Element exclusion: Mark elements with a CSS class (often rr-block or similar) to exclude them from recording entirely. The element is still visible in the replay as a gray box but its content isn't captured.

Text masking: Replace all text content with x characters. The highest-privacy option, but makes replays harder to use.

The data-transfer issue is separate from what gets captured. When you use a SaaS replay tool, the serialized DOM snapshots — including any content you didn't mask — leave your infrastructure. Under GDPR, this likely constitutes a transfer of personal data, which requires a Data Processing Agreement with the vendor and, if you have EU users and the vendor is US-based, Standard Contractual Clauses.

The tools compared

FullStory — The enterprise option. Deep session data, rage-click detection, DX Data analytics, and an API for programmatic access. Pricing starts around $300/mo for 1,000 sessions and climbs steeply at volume. Data lives on FullStory's US servers.

Hotjar — The mid-market option. $39/mo for 100 recorded sessions per day (about 3,000/mo). Adds heatmaps and user surveys. Simpler interface than FullStory.

LogRocket — Developer-focused. In addition to session replay, it captures Redux state, network requests, and console logs. Particularly useful for debugging — you get the full application context, not just the visual replay. Pricing starts around $99/mo.

PostHog Replay — Part of PostHog's broader product analytics platform. If you're already using PostHog for event analytics, the session replay is included (up to 5,000 recordings/mo on the free tier). Built on rrweb, same as the others. Self-hostable.

Microsoft Clarity — Free. No session limits. Surprisingly capable: session replay, heatmaps, rage-click detection. The catch is that data goes to Microsoft. Clarity's terms allow Microsoft to "use the data for Microsoft's business purposes." For non-critical sites where data residency isn't a concern, it's compelling given the price.

Self-hosted with rrweb — You can use rrweb directly, record sessions to your own infrastructure, and build a replay UI on top of it. This is what tools like OpenReplay and Highlight.io do, and what some teams build in-house. OpenReplay is fully open-source and deployable with Docker Compose. You own the data. The tradeoff is operational overhead.

When do you actually need session replay?

Not every app needs it. Session replay adds a non-trivial script to your page (usually 50-100KB) and generates storage costs. Worth it in these situations:

High checkout or conversion funnel abandonment. "12% of users drop off at step 3" is an analytics fact. Why they drop off requires watching them.

Vague bug reports. "It just doesn't work" tells you nothing. A session replay of that user shows you exactly what they clicked and what the page showed in response.

Onboarding confusion. Where do new users get stuck? Watching 20 onboarding sessions tells you more than most quantitative analyses.

Accessibility issues. Keyboard-only navigation problems, tab order issues, and focus traps show up clearly in replays in ways that automated tests miss.

Less useful for high-traffic content sites where most pages are informational and user behavior is predictable. More useful for apps with complex workflows, multi-step forms, or frequent user-reported "broken" experiences.

Storage cost math

If you're self-hosting, the storage math matters. At 200KB average per session (after compression), 10,000 sessions/month is 2GB. 100,000 sessions/month is 20GB. A year of sessions at that volume is 240GB — about $5-6/mo on object storage.

For most teams, storage cost for self-hosted replay is negligible compared to SaaS pricing. The main operational cost is running the service and maintaining the replay infrastructure. Tools like OpenReplay abstract that away; raw rrweb requires you to build it.

The question to ask: does the debugging and UX value of replay justify the cost (money, storage, operational overhead, and privacy audit work) at your current traffic level? For most teams under 1,000 sessions/day, the answer is yes if you're running a complex product. For simple sites, probably not.

How Git-Push Deployments Work Under the Hood

DAVID VIEJO — Fri, 20 Mar 2026 06:50:49 +0000

git push deploys to production. It's the workflow that Heroku popularized, Vercel polished, and dozens of tools since have copied. But most developers who use it every day don't know what's happening between the push and the live URL. Understanding the pipeline helps you debug it when it breaks and make smarter decisions about your deployment setup.

Here's what happens at each step.

Step 1: The Webhook Fires

When you push to a repository on GitHub, GitLab, or Gitea, the platform sends an HTTP POST to any webhooks registered for that repo. The payload includes the commit SHA, the branch name, the repository URL, and the pusher's identity.

Your deployment platform registers one of these webhooks when you connect a repository. On Vercel, it happens automatically when you import a project. On Coolify, Dokploy, or a self-hosted tool, you configure it from the dashboard during project setup.

The webhook request is just an HTTP POST. Your deployment server needs a public IP and an open port to receive it. This is why deployment platforms need to be accessible from the internet, not just from your private network.

One thing worth knowing: GitHub will retry a webhook if your server doesn't respond with a 2xx status within 10 seconds. If your build system is slow to acknowledge, you can end up with duplicate builds. Well-built platforms deduplicate by commit SHA.

Step 2: The Build Queue

The deployment server receives the webhook, parses the payload, and queues a build job. It stores the commit SHA, the branch, and a pointer to the repository.

Queuing matters because pushes can come faster than builds complete. If two developers push within 30 seconds of each other, the second push should wait for the first build to finish (or cancel it, depending on the platform's configuration). Naively triggering a concurrent build for every push causes resource contention and race conditions on the traffic swap.

Platforms handle this differently: Vercel runs builds in parallel on separate infrastructure. Coolify queues them on your server. The right behavior depends on whether you have enough build capacity to run concurrently.

Step 3: Clone and Detect

The build agent clones the repository at the specific commit SHA. This is always a specific SHA, not just the branch head, because the branch might advance between when the webhook fired and when the build starts.

After cloning, the build system detects how to build the app. There are two common approaches:

Dockerfile detection. If a Dockerfile is present at the root, use it. The developer has already specified the build process. This is the most explicit option and the least surprising.

Buildpacks. If there's no Dockerfile, Cloud Native Buildpacks (CNB) scan the repository for language indicators: a package.json suggests Node.js, a requirements.txt suggests Python, a go.mod suggests Go. The matching buildpack downloads the right runtime, installs dependencies, and produces a container image. Heroku pioneered this model; the CNB specification standardized it.

The advantage of buildpacks: you push code without a Dockerfile and the platform figures it out. The downside: if your app needs something non-standard, the buildpack's defaults might not be right, and debugging why takes longer than just writing a Dockerfile.

Step 4: The Container Build

The actual build runs inside Docker (or a Docker-compatible builder like BuildKit). For a Node.js app, this means npm ci followed by your build command. For a Python app, pip install. For a Go binary, go build.

Build logs stream in real time to the dashboard. This is worth appreciating: you're watching exactly what would happen if you ran docker build locally. If the build fails because a dependency version is missing or an environment variable is undefined, the error is right there in the log.

A detail that matters for build speed: Docker layer caching. A well-structured Dockerfile copies package.json and runs npm install before copying the rest of the source code. That way, the installed dependencies layer gets cached between builds, and only the application code layer gets rebuilt on each push. A poorly structured Dockerfile invalidates the cache on every build. The difference is 30 seconds versus 4 minutes for a typical Node.js app.

Step 5: Health Check Before Traffic Switch

Before the new container gets any production traffic, most deployment platforms run a health check. The new container starts, and the platform pings a health endpoint (usually /health or just /) and waits for a 200 response.

This step is what makes zero-downtime deployment possible. The old container keeps serving requests while the new one warms up. If the new container never passes its health check (because the new code has a startup bug, or the database migration failed, or a required environment variable is missing), it never receives traffic. The old version stays live.

Without a health check, the platform would just replace the old container with the new one and hope. Sometimes it works. Sometimes users get 502 errors for 10-30 seconds while the new container cold-starts.

Step 6: The Traffic Swap

Once the new container passes its health check, the proxy routes new requests to it. The mechanism varies by platform:

Nginx-based platforms update an upstream block and reload the nginx config. This works but has a brief gap where in-flight requests can be interrupted.

Traefik (used by Coolify and Dokploy) supports dynamic configuration: it picks up the new container via Docker labels without restarting. In-flight requests on the old container are generally handled gracefully, though the behavior depends on Traefik's version and configuration.

Edge networks (Vercel, Cloudflare) route traffic via their global infrastructure with connection draining behavior, ensuring in-flight requests complete on the old version before it's removed.

The key distinction is between "stop sending new requests to old container" and "wait for old requests to finish before stopping the old container." The second is harder to implement correctly, but it's the difference between zero-downtime and almost-zero-downtime.

Step 7: Cleanup

After traffic moves to the new container, the old container stops. Container images from old deploys get retained for a configurable period (to support rollbacks) and then pruned. Build artifacts get cleaned up.

This cleanup step is easy to neglect in a DIY setup and causes a subtle problem: if you're running frequent deploys, old Docker images accumulate and fill your disk. Platforms handle this automatically; a bare Docker setup needs a cron job running docker system prune.

The Full Pipeline, Summarized

git push
  → webhook fires (HTTP POST to your deployment server)
  → build queued (deduplicated by SHA)
  → repository cloned at commit SHA
  → build detection (Dockerfile or buildpacks)
  → container build (Docker, logs stream to dashboard)
  → health check (new container must pass before traffic switches)
  → traffic swap (proxy re-routes requests to new container)
  → old container drains and stops
  → image cleanup

Every platform that does git-push deploys, whether it's Vercel, Netlify, Coolify, Heroku, or a self-hosted tool, runs some version of this same pipeline. The differences are in speed, correctness of the traffic swap, and what you have to configure manually versus what's automatic.

When a deploy fails, it's almost always at one of three steps: the build (a code error), the health check (a startup bug or missing env var), or the traffic swap (a proxy misconfiguration). Knowing which step failed cuts your debugging time in half.

How to Deploy a Next.js App to a VPS (The Manual Way)

DAVID VIEJO — Fri, 20 Mar 2026 06:50:46 +0000

Most Next.js tutorials end at npm run dev. The deployment section says "push to Vercel" and moves on.

That's fine until you need to own your infrastructure, keep costs under control, or just understand what's actually happening when your app goes live. This post walks through deploying a Next.js app to a bare VPS, step by step. No platform, no abstraction layer. Just you, a server, and the commands.

By the end, you'll understand every piece of the deployment pipeline. And you'll be able to decide whether you want to keep doing it manually or hand it off to a tool.

What You Need

A VPS from any provider (Hetzner, DigitalOcean, Linode, Vultr, whatever). 2GB RAM minimum for a Next.js app with a build step. 4GB if you're running a database on the same box.
A domain name pointed at your server's IP address.
SSH access to the server.
A Next.js app that builds successfully with npm run build on your local machine.

This guide assumes Ubuntu 22.04 or 24.04. Debian works too with minor differences.

Step 1: Set Up the Server

SSH into your new server:

ssh root@your-server-ip

Update packages and install the basics:

apt update && apt upgrade -y
apt install -y curl git ufw

Set up the firewall. Open SSH, HTTP, and HTTPS. Close everything else:

ufw allow OpenSSH
ufw allow 80
ufw allow 443
ufw enable

Create a non-root user (running everything as root is asking for trouble):

adduser deploy
usermod -aG sudo deploy

Copy your SSH key to the new user:

rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

Log out and log back in as the deploy user from now on.

Step 2: Install Node.js

Don't install Node from apt. The version in Ubuntu's default repos is usually ancient. Use the NodeSource repository:

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs

Verify:

node --version  # Should be 20.x
npm --version

If your project uses a specific Node version (check .nvmrc or engines in package.json), match it here. Mismatched Node versions between local and server are one of the most common causes of "works on my machine" deployment failures.

Step 3: Clone and Build Your App

cd /home/deploy
git clone https://github.com/your-username/your-nextjs-app.git
cd your-nextjs-app
npm ci

npm ci instead of npm install. It installs from the lockfile exactly, which is what you want in production. npm install can resolve to different versions.

Set your environment variables:

cp .env.example .env.production
nano .env.production
# Fill in your production values: DATABASE_URL, API keys, etc.

Build:

npm run build

If this fails, fix it before continuing. Common issues: missing env vars that the build needs at compile time (Next.js bakes NEXT_PUBLIC_* variables into the client bundle during build), or native dependencies that need build tools (sudo apt install -y build-essential).

Step 4: Run the App with PM2

You need a process manager. If you just run npm start in your terminal and disconnect, the process dies. PM2 keeps it running, restarts it if it crashes, and manages logs.

sudo npm install -g pm2

Start your app:

pm2 start npm --name "nextjs-app" -- start

Check it's running:

pm2 status
pm2 logs nextjs-app

By default, Next.js starts on port 3000. Verify it's listening:

curl http://localhost:3000

Tell PM2 to start your app on server boot:

pm2 startup
pm2 save

The pm2 startup command prints a line you need to copy and run with sudo. Don't skip it, or your app won't survive a server reboot.

Step 5: Install and Configure Nginx

Nginx sits in front of your Next.js app. It handles SSL termination, serves static files, and proxies dynamic requests to your Node process.

sudo apt install -y nginx

Create a site config:

sudo nano /etc/nginx/sites-available/your-app

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
    }
}

Enable the site:

sudo ln -s /etc/nginx/sites-available/your-app /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

The proxy_set_header Upgrade and Connection 'upgrade' lines are for WebSocket support. If your app uses real-time features, these headers are required.

At this point, your app should be accessible at http://yourdomain.com. No SSL yet.

Step 6: SSL with Let's Encrypt

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

Certbot modifies your Nginx config to add SSL, sets up automatic certificate renewal, and redirects HTTP to HTTPS.

Verify the renewal timer is active:

sudo systemctl status certbot.timer

Certificates expire every 90 days. Certbot's timer renews them automatically. If you skip this check and the timer isn't running, your site goes down in 3 months with an expired cert. It happens more often than you'd think.

Step 7: Set Up Deployments

Your app is live. Now you need a way to update it when you push new code.

Create /home/deploy/deploy.sh:

#!/bin/bash
set -e

cd /home/deploy/your-nextjs-app

echo "Pulling latest code..."
git pull origin main

echo "Installing dependencies..."
npm ci

echo "Building..."
npm run build

echo "Restarting..."
pm2 restart nextjs-app

echo "Done."

chmod +x /home/deploy/deploy.sh

Automating with GitHub Actions

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to VPS
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_IP }}
          username: deploy
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: /home/deploy/deploy.sh

Add SERVER_IP and SSH_PRIVATE_KEY to your repo's GitHub Secrets.

Now every push to main triggers the deploy script over SSH.

What This Doesn't Handle

The deploy script above has real gaps:

No health check. If the new build is broken, PM2 restarts the old process, but there's a window where requests fail.
No rollback. If the deploy breaks the app, you have to manually revert.
No preview environments. Every push to main goes straight to production.
Downtime during restart. PM2's restart kills the old process and starts the new one. There's a 1-3 second gap with 502 errors.

You can solve each of these individually (blue-green deploys with Nginx upstream toggling, a webhook server, PM2's cluster mode). But each solution adds complexity, and by the time you've built all of them, you've built a deployment platform.

Step 8: Monitoring (The Part Most Tutorials Skip)

Your app is deployed. How do you know it's still running tomorrow?

Logs: PM2 handles application logs. Rotate them or they'll fill your disk:

pm2 install pm2-logrotate

Uptime: You need something that pings your site and alerts you when it's down. Free options: UptimeRobot, Betterstack (free tier), or a cron job that curls your health endpoint.

Error tracking: When your app throws an unhandled exception in production, how do you find out? Sentry (free tier), LogRocket, or parsing PM2 logs manually.

Analytics: Google Analytics, Plausible, Umami, or similar.

Each of these is a separate tool, a separate account, a separate dashboard.

The Full Stack of What You Just Built

Let's count:

Running on your server:

Node.js (runtime)
PM2 (process manager)
Nginx (reverse proxy, SSL termination)
Certbot (certificate renewal)
Git (code delivery)
GitHub Actions (build automation)

Still need but didn't set up:

Uptime monitoring (external service)
Error tracking (external service)
Analytics (external service)
Log management (PM2 + logrotate, or external service)

That's 6 things on your server and 4 external services for a single Next.js app.

Or: Skip All of That

The manual approach works. But there's a reason deployment platforms exist.

If you want the git push workflow without managing Nginx, PM2, Certbot, deploy scripts, and GitHub Actions yourself:

Vercel is the obvious choice for Next.js. They built the framework. Free tier is generous. Costs scale fast with traffic.
Coolify is open-source, self-hosted. Handles Docker, Traefik proxy, SSL, and git-push deploys. Good community.
Dokploy is another open-source option, simpler than Coolify, focused on minimal configuration.
Kamal (from the Rails team) deploys Docker containers to any server over SSH. Minimal abstraction.
Temps is what I build. Single Rust binary that handles deployments plus analytics, error tracking, uptime monitoring, and session replay. One tool instead of 10. Smaller community, dashboard isn't as polished as Vercel's. Open source and free to self-host.

The point of this tutorial isn't to talk you out of doing it manually. It's to make sure you know what "deploying to production" actually involves, so you can make an informed choice.

I built an open-source Vercel alternative in Rust — here's what I learned

DAVID VIEJO — Wed, 18 Feb 2026 08:54:40 +0000

I come from a DevOps and blockchain background. I've spent years managing infrastructure, wrangling containers, and thinking about how systems should be architected. So when I started shipping web apps and saw what developers were paying for deployment platforms, something felt off.

Vercel's DX is incredible — I won't pretend otherwise. git push and your app is live. But then you look at the bill: $20/seat/month. Bandwidth overages. And that's just hosting. You still need Sentry for error tracking ($26/mo), something like PostHog for session replay and analytics, an uptime monitoring tool, maybe a transactional email service. Suddenly you're juggling six SaaS subscriptions for what is fundamentally one job: running your app and knowing what's happening inside it.

As someone who's managed infrastructure professionally, I kept thinking: all of this can run on a single $20 VPS. The data is just HTTP requests, error payloads, and time-series metrics. There's no technical reason this needs to be six separate services.

So I built Temps.

What is Temps, in one sentence

An open-source, self-hosted deployment platform with built-in analytics, error tracking, session replay, uptime monitoring, and transactional email. Runs on any VPS. Dual-licensed under MIT and Apache 2.0.

curl -fsSL https://temps.sh/deploy.sh | sh

That's the entire install. One command, on any Linux server. From bare server to first deployment in under 3 minutes.

Why Rust

I didn't start with Rust. The first prototype was Node.js. It worked, but the resource footprint was brutal — the deployment server itself was eating 800MB of RAM just idling. When the thing that deploys your apps needs more resources than the apps it's deploying, something is wrong.

Rust brought that down dramatically. But the real win was Cloudflare Pingora — their open-source proxy engine. Pingora handles reverse proxying, TLS termination (with dynamic SNI-based certificate loading), HTTP/2, and connection management. Building on top of it meant I got battle-tested networking code from a company that handles a significant chunk of internet traffic, instead of writing my own proxy from scratch.

The stack ended up being:

Rust — 51 workspace crates covering the entire platform
Axum — HTTP framework for the API
Sea-ORM — database access layer
Pingora — Cloudflare's proxy engine for reverse proxying and TLS
Bollard — Docker API client for container management
PostgreSQL + TimescaleDB — app data + time-series analytics/metrics

Everything runs as a single binary. No Kubernetes. No microservices. One process that handles deployments, proxying, analytics ingestion, error collection, monitoring, email, and more. My DevOps background made me appreciate this kind of simplicity — fewer moving parts means fewer things to debug at 3am.

The hard problems nobody warns you about

Building a deployment platform sounds straightforward until you actually try it. Here's what surprised me.

Zero-downtime deployments

The naive approach — stop old container, start new one — creates a gap. Even a 2-second gap means dropped requests and angry users.

Temps uses a blue-green deployment pattern:

Build the new container image
Deploy and health check the new container alongside the old one (HTTP health checks with a configurable timeout, up to 300 seconds)
Shift traffic to the new container once health checks pass
Tear down the old container only after the new one is confirmed healthy

If the new container fails health checks or crashes, the old container stays running and the deployment is marked as failed. No downtime.

Framework auto-detection is a rabbit hole

"Just detect the framework from the project files" sounds simple. In practice:

A project with both next.config.js and a Dockerfile — which one wins?
A Python project with requirements.txt, Pipfile, AND pyproject.toml — which dependency manager?
A Node.js project — is it Next.js, Vite, Nuxt, Remix, Astro, NestJS, or plain Express?
A monorepo with 4 different frameworks in subdirectories

I built a detection system that reads package.json dependencies, checks for framework-specific config files, and detects package managers from lock files (npm, yarn, pnpm, bun). It handles Next.js, Vite, Astro, Nuxt, Remix, NestJS, Vue, Express, Docusaurus, CRA, Rsbuild, Python, Go, Rust, Java, .NET, and anything with a Dockerfile. The Dockerfile always wins if present.

Each detected preset generates a Dockerfile automatically. The result: most projects deploy with zero configuration.

bunx @temps-sdk/cli deploy

No temps.json. No temps.yaml. No build configuration file. It just figures it out.

Sentry-compatible error tracking

I didn't want to build a toy error tracker. I wanted something you could actually use in production instead of Sentry.

The key decision: make it Sentry-compatible at the protocol level. Temps implements the Sentry envelope format — it parses events, transactions, sessions, and spans using relay-event-schema (Sentry's own Rust types). If you're already using @sentry/nextjs or sentry-sdk for Python, you change one line — the DSN endpoint — and your errors flow into Temps instead.

// Before
Sentry.init({ dsn: "https://abc@sentry.io/123" });

// After
Sentry.init({ dsn: "https://abc@your-server.com/123" });

Same SDK. Same error grouping. Same stack traces. Source map support included. Zero per-event fees.

I'd rather be compatible with the ecosystem than force people to learn a new tool.

Session replay with rrweb

The session replay feature uses rrweb — the same recording library used by PostHog, LogRocket, and others. The React SDK (@temps-sdk/react-analytics) records DOM mutations and user interactions on the client, compresses them with zlib, and sends them to Temps where they're stored alongside the rest of your analytics data.

You can watch real user sessions directly in the Temps dashboard, correlated with errors, page views, and performance data. No separate session replay subscription needed.

What I got wrong

I'll save you the hero narrative. I made plenty of mistakes building this solo.

I underestimated managed databases. The first version required you to set up your own PostgreSQL and Redis. Nobody wanted to do that. Temps now provisions Postgres, Redis, S3 (via RustFS), and MongoDB alongside your apps — handles creation, backups, and teardown.

The first CLI was overengineered. It had too many flags and options. I rewrote it to have sensible defaults for everything. Now the most common flow is two commands:

bunx @temps-sdk/cli init
bunx @temps-sdk/cli deploy

I tried to build a dashboard before the CLI was solid. The dashboard is nice for monitoring — it has a web terminal (xterm.js), a code editor (Monaco), charts (Recharts), and the rrweb session replay player. But engineers live in the terminal. Getting the CLI experience right first was the correct order of operations — I just didn't do it in that order.

What surprised me: the MCP server

One thing I didn't plan from the start but ended up building: a Model Context Protocol server (@temps-sdk/mcp). MCP is the standard that lets AI assistants interact with external tools.

With the Temps MCP server, an AI agent like Claude can deploy your apps, check deployment status, and manage your infrastructure through natural language. You add it to your Claude Desktop config:

{
  "mcpServers": {
    "temps": {
      "command": "npx",
      "args": ["@temps-sdk/mcp"]
    }
  }
}

And now your AI assistant can talk to your deployment platform directly. It's a small thing, but it fits a pattern I believe in: meet developers where they already work. If that's the terminal, build a great CLI. If that's an AI assistant, build an MCP server.

The economics

Here's the math that motivated this whole project — what a typical developer or small team pays to run production apps:

What you get with Temps	Instead of paying for
Git deployments + preview URLs	Vercel / Netlify ($20+/mo)
Web analytics + funnels	PostHog / Plausible ($0-450/mo)
Session replay	PostHog / FullStory ($0-2000/mo)
Error tracking (Sentry-compatible)	Sentry ($26+/mo)
Uptime monitoring + status pages	Better Uptime / Pingdom ($20+/mo)
Managed Postgres/Redis/S3/MongoDB	AWS RDS / ElastiCache ($50+/mo)
Transactional email + DKIM	Resend / SendGrid ($20-100/mo)
Request logs + proxy	Cloudflare ($0-200/mo)
KV store + blob storage	Vercel KV / S3 ($0-50/mo)
Total with Temps	$0 (self-hosted on your VPS)

As an indie, that difference is real money. It's the difference between burning runway and not.

What Temps supports today

To be concrete about where the project is — this is a 51-crate Rust workspace, not a weekend project:

Frameworks: Next.js, Vite, Astro, Nuxt, Remix, NestJS, Vue, Express, Docusaurus, Python, Go, Rust, Java, .NET, and anything with a Dockerfile.

Deployment:

Git push deployments (GitHub and GitLab)
Preview deployments per branch/PR
Zero-downtime blue-green deployments
Automatic SSL via Let's Encrypt (HTTP-01 and DNS-01)
Custom domains with automatic TLS
Environment variables and secrets (AES-256 encrypted at rest)

Built-in observability:

Web analytics with funnels and visitor tracking
Session replay (rrweb-based)
Error tracking (Sentry-compatible — same SDK, change one line)
Uptime monitoring with alerts (email, Slack, webhooks)
Request-level logging (method, path, status, response time)
Performance tracking (Web Vitals)

Infrastructure:

Managed PostgreSQL, Redis, S3 (RustFS), and MongoDB
KV store (@temps-sdk/kv — Redis-like API)
Blob storage (@temps-sdk/blob — S3-compatible)
Transactional email with DKIM verification
Vulnerability scanning (Trivy-based)
Status pages with incident management

Developer tools:

MCP server for AI agents (@temps-sdk/mcp)
React analytics SDK (@temps-sdk/react-analytics)
Node.js SDK with Sentry-compatible error tracking (@temps-sdk/node-sdk)
TypeScript CLI (bunx @temps-sdk/cli)
Web dashboard with terminal, code editor, and session replay player

Infrastructure: Runs on any Linux VPS — AWS, GCP, Azure, DigitalOcean, Hetzner, your own hardware.

Who should NOT use Temps

I believe in being honest about trade-offs:

If you're on Vercel's free tier — Vercel's free tier is genuinely great. Temps doesn't make sense until you're paying.
If you need edge computing — Temps runs on your servers, not a global edge network. If sub-50ms latency from every continent matters, Vercel or Cloudflare is better.
If you want zero ops — Temps is self-hosted. It's dramatically simpler than raw Docker or Kubernetes, but it's not zero-ops. You're still responsible for a server.
If cost isn't a concern — If you have the budget, Vercel's ecosystem and managed infrastructure is hard to beat.

What I'd tell someone building an open-source tool solo

A few things I've learned that I wish someone told me:

Compatibility beats originality. Making the error tracking Sentry-compatible (using their actual relay-event-schema types) instead of inventing a new protocol was the single best technical decision. Users can try it with a one-line change and zero risk.

The install experience IS the product. If your open-source tool takes more than 5 minutes to set up, most people will never try it. The one-liner install took an unreasonable amount of engineering effort — auto-detecting OS, architecture, setting up services, configuring PostgreSQL with TimescaleDB, initializing encryption keys — but it's worth it.

Don't build for everyone. Temps is for developers and small teams who are paying for hosting and want to own their infrastructure without the DevOps overhead. That's a specific group, and that's fine.

Build for the workflow, not just the feature. Adding the MCP server wasn't on my roadmap. But developers are increasingly working through AI assistants, and if Temps can be part of that workflow natively, it removes friction. Same logic applies to the CLI, the SDKs, the Sentry compatibility. Meet people where they are.

Try it

If any of this resonates:

curl -fsSL https://temps.sh/deploy.sh | sh

The CLI is free forever. The source code is on GitHub — 51 Rust crates, dual-licensed MIT/Apache 2.0.

If you run into issues or want to chat, the Discord is active and I'm usually around.

Temps isn't perfect — it's not. But I think the idea that your deployment platform should include observability, email, storage, and AI integration by default, at no extra cost, on infrastructure you control, is the right direction. And I'd rather build that in the open than behind a paywall.

If you've dealt with SaaS cost sprawl or have opinions on self-hosted vs managed, I'd love to hear your take in the comments.