DEV Community: Cristian Iridon

We stopped sharing one staging server — here's what we built instead

Cristian Iridon — Sun, 03 May 2026 21:13:30 +0000

We stopped sharing one staging server — here's what we built instead

Every team I've been on has had the same problem.

You have 4 engineers. You have one staging server. Every morning there's a Slack message: "who's on staging right now?" Someone has to wait. Someone always merges before QA finishes. Someone's PR sits in review for 3 days because the environment is occupied.

The frontend teams solved this years ago. Vercel gives you a preview URL for every branch automatically. It's genuinely great — if your stack is Next.js.

But if you're running Django, Rails, Laravel, FastAPI, Spring Boot, or anything else that needs a real backend process? You're stuck with the shared staging server. Or you spend two weeks wiring up Kubernetes preview environments.

We got tired of it and built PreviewDrop.

How it works

PreviewDrop spins up an isolated Docker environment for every GitHub branch or pull request. Each environment gets its own URL. When the PR closes, the environment is automatically cleaned up.

Setup is one command:

npx previewdrop init

That writes a GitHub Actions workflow file to your repo. After that, every PR gets a preview URL automatically — no manual steps, no shared state, no "who's on staging" Slack messages.

What it supports

If it runs in Docker, PreviewDrop can preview it. That includes:

Django (the one Vercel explicitly can't do)
Rails
Laravel
FastAPI
Spring Boot
Node/Express
Any custom Dockerfile

What it costs

$19/mo flat for the Starter plan — 5 concurrent previews, 3 team members. No per-second billing, no per-seat fees, no surprises at month end.

Compare that to Railway's pay-per-second model, which gets unpredictable fast when you're spinning up preview environments 20 times a day.

Who it's for

Three use cases where it genuinely solves a real problem:

1. Agency developers sending clients preview links
You're building a Django or Rails site for a client. They need to review the new feature. Right now you either keep a staging server running 24/7 (costs money, needs maintenance) or you send a Loom video. With PreviewDrop, you send a URL.

2. Small product teams with a QA bottleneck
One staging environment + multiple engineers = a queue. PreviewDrop gives every PR its own environment. QA can test 5 PRs in parallel.

3. Teams that evaluated Kubernetes-based solutions and gave up
Bunnyshell is powerful but the onboarding assumes you have a platform engineer with Kubernetes experience. PreviewDrop is Docker — if you can write a Dockerfile, you're done in under 10 minutes.

What we're not

To be clear: PreviewDrop is not production hosting. The environments are ephemeral. If you need Vercel-style CDN and ISR for a Next.js frontend, use Vercel — it's genuinely better for that use case.

PreviewDrop is for the backends that Vercel can't run.

Try it

We're in public beta. Free tier available, no credit card required.

→ previewdrop.dev

The GitHub App install takes about 90 seconds. If you have a Dockerfile, you'll have your first preview URL before your next coffee.

Feedback welcome — what's missing? What would make you actually switch?

Instant Preview Environments Under the Hood: Docker, WebSockets, and PreviewDrop

Cristian Iridon — Sun, 03 May 2026 20:18:42 +0000

A pull request sits open for four days because the backend change can't be reviewed without running it. Someone spins up a staging server manually. Someone else opens an ngrok tunnel from their laptop and forgets to close it. The client asks for a link and gets a screenshot instead.

We've been that engineer. We built PreviewDrop to stop being that engineer.

The core promise is simple: push a feature branch, get a live HTTPS URL posted to the pull request as a commit status check. The container runs, serves traffic, self-destructs when your TTL expires. No staging server to maintain. No ngrok tunnel to keep alive.

But the "simple" part took some doing. Here's the architecture that makes it work.

Why Most Preview Tools Don't Work for Backend Stacks

Vercel preview deployments are excellent — for Next.js. Render's PR previews work for web services that fit their build pipeline. But backend stacks are different. Django, Rails, Laravel, FastAPI, Spring Boot — these are long-lived processes in containers. They need a database connection, environment variables injected at runtime, background workers that might need to start, and WebSocket support that doesn't degrade.

A preview environment for a backend stack isn't a static deploy. It's a full container that needs to boot, bind a port, accept traffic, and stay healthy until the review is done. That requires infrastructure decisions most preview tools don't make — and it's where Docker becomes the foundation.

PreviewDrop's rule is: if it runs in Docker, it previews. No framework adapter. No serverless wrapper. No YAML manifest describing how to shape your app into a preview-shaped box. A working Dockerfile in the project root is the only prerequisite.

The Architecture: Docker, WebSockets, and a Next.js Control Plane

Three layers do the work.

Layer 1 — The container runtime. Every preview is a Docker container running on a managed worker node. When GitHub Actions triggers a build (via the workflow file that npx previewdrop setup writes), the image is pushed to a private registry. PreviewDrop pulls it, injects environment variables from the project's dashboard settings, and starts the container with the port your app exposes. The container gets a health check, a TTL, and an HTTPS reverse proxy route. It lives until the TTL expires or the PR merges — whichever comes first.

Layer 2 — WebSocket coordination. This is where it gets interesting. Building a container image and starting it takes time — anywhere from 30 seconds to a few minutes depending on the stack. During that window, the user is staring at a PR status check that says "pending." The dashboard needs to show real-time progress: image pull started, container starting, health check passing, URL assigned.

We use WebSockets for that pipeline of state transitions. The control plane pushes an event stream: build_registered → image_pulled → container_allocated → starting → healthy → url_assigned. The dashboard subscribes to the relevant project channel and renders each stage as it happens. The PR commit status updates at the final healthy transition, with the URL attached.

No polling. No spamming the API every 3 seconds waiting for a status field to flip. The WebSocket connection stays open for the life of the preview, pushing state changes and container logs. If the container exits unexpectedly, the event stream surfaces the exit code and the last log lines to the dashboard before the status goes red.

Layer 3 — The Next.js dashboard. This is the surface area users actually touch. The dashboard is a Next.js app that handles authentication (GitHub OAuth), project management, environment variable configuration, deployment logs, and the live preview list. It consumes the WebSocket feed from layer 2 and renders the deployment pipeline in real time.

Next.js was the right choice here because the app is mostly server-rendered pages with some client-side reactivity for the deployment pipeline and log viewer. The API routes in /api/v1/ expose a programmatic interface for the CLI and CI workflows. The dashboard isn't a separate service — it's the same Next.js app, which keeps the architecture simpler than splitting into a separate SPA.

How the Share Link Actually Works

When a preview reaches the healthy state, the control plane generates a shareable URL with a unique token. This is the link posted to the PR commit status. It's also the link you can send to a client, a PM, or a stakeholder who doesn't have a GitHub account.

The share link is a reverse proxy route through the control plane. A request hits https://{token}.previewdrop.dev (or a subpath on the main domain, depending on configuration), the proxy resolves the token to the correct container on the correct worker node, and the request is forwarded. TLS terminates at the edge. The container never sees the proxy — it just gets HTTP traffic on the port it bound.

The link is password-protectable (enabled in the dashboard per preview). The TTL is configurable per project — 1 hour minimum, up to 168 hours (one week) on the Team plan. When the TTL expires, the container is stopped, the route is removed, and the token is invalidated. No zombie containers. No URLs that still work six months later and confuse someone looking at a stale Google index entry.

This is the feature that replaces the "staging server shared across PRs" workflow. Instead of one staging URL that everyone steps on, every PR gets its own isolated container and its own URL. Review one branch at a time, share a link that can't accidentally show the wrong branch's code, and stop coordinating deploys to staging.

What Happens When a Container Dies

Containers fail. Out-of-memory kills. Unhandled exceptions. Missing environment variables that cause a crash-loop. The architecture needs to handle this gracefully.

The worker node monitors container health via a periodic HTTP check to the app's exposed port. If the check fails three consecutive times, the container is marked unhealthy. The WebSocket connection pushes an unhealthy event with the exit code (if the container exited) or the last error response (if it's still running but broken). The dashboard shows the status change and surfaces the most recent log lines.

If the container is crash-looping — starts, fails, restarts, fails — the worker node detects the pattern and stops restarting after the third attempt. The dashboard shows a crashed state with the failure reason extracted from the container exit log. No infinite restart loops burning CPU on the worker node.

Environment variable misconfiguration is the most common cause. The dashboard's "Scan .env.example" feature detects which variables your app expects and flags any that aren't set in the preview environment. If a preview is returning a 500, that's usually the fix.

The Build Pipeline in Practice

Here's what a push looks like end to end.

A developer pushes a feature branch to GitHub. GitHub Actions picks up the previewdrop.yml workflow, builds the Docker image, tags it with the branch name and commit SHA, and pushes it to the PreviewDrop registry. The workflow triggers the PreviewDrop API: "new image available for project X, branch Y, commit Z."

The control plane assigns a worker node, pulls the image, starts the container with the project's environment variables, and begins the health check loop. The WebSocket feed pushes state transitions to the dashboard. When the container passes its health check, the URL is generated, the route is activated, and the PR commit status updates to "success" with the preview URL attached.

The whole pipeline from push to live URL typically finishes in 45–90 seconds for most Django, Rails, and Laravel apps with a reasonably-sized Docker image. Cold starts (first build on a new worker) add another 20–40 seconds for the image pull. Subsequent builds on the same worker node are faster because the base layers are cached.

The PR stays open for review. Feedback comes in. The developer pushes a new commit. The pipeline runs again — new image, new container, new URL, same commit status update. The old container self-destructs on the next TTL cycle.

The Pricing Model That Made Architecture Decisions Possible

Usage-based billing creates design pressure. If you bill per container-second, every optimization looks like an opportunity to charge more — longer build times, longer health checks, no auto-cleanup. You don't want containers to self-destruct quickly because every second is revenue.

Flat pricing removes that incentive. PreviewDrop Starter is $19/month per workspace. That covers 5 concurrent previews, up to 3 team members, and a 4-hour TTL per container. The same $19 whether your team has a quiet week with two PRs or a crunch sprint with ten. The same $19 whether previews run for one hour or the full four.

When billing doesn't punish usage, teams use the product more — more reviews, more client shares, fewer coordination bottlenecks. That's the behavior you want. It's also the behavior per-second pricing accidentally discourages.

The free tier is two concurrent previews and three projects. No credit card required. It's enough to evaluate whether the workflow fits your team.

What's Launching May 20th

PreviewDrop is launching on Product Hunt on May 20, 2026. The free tier ships that day — two concurrent previews, three projects, no credit card. The setup is the same one-command flow: npx previewdrop setup writes the workflow file and prints the secret.

If your backend runs in Docker and your team has more than one open PR right now, try the free tier when we launch. You'll have a live preview URL on your next push.

Follow the launch at previewdrop.dev. See you May 20th.

Why Preview Environments Matter for Solo Developers (Stop Merging Blind)

Cristian Iridon — Sun, 03 May 2026 19:28:23 +0000

\"Works on my machine\" is the lie every developer has told themselves. It worked at 2am on your laptop. It passed the unit tests. You merged it. Then production got a 500, the client noticed, and your afternoon disappeared into a firefight that started with a merge you were sure was safe.

The problem isn't you. It's the gap between your machine and production — and most teams fill that gap with a single staging server that creates as many problems as it solves.

The Staging Server Queue

Staging environments sound reasonable. Spin up one server that mirrors production, deploy every branch to it before merging, catch bugs early. In theory.

In practice, a staging server is a shared resource. When you're ready to test your branch, someone else's build is already running. Or their database migration broke the schema your branch depends on. Or their half-finished feature is throwing console errors that look like yours. You waste twenty minutes debugging a problem you didn't cause, then wait your turn.

Multiply that across five developers with three open PRs each, and staging becomes the bottleneck nobody budgets for. Deploy frequency drops. PRs sit open longer. Reviewers stop testing locally because "someone will catch it in staging" — and then nobody does.

The result is the exact opposite of what you wanted: merges get less safe, not more, because the staging server trained your team to skip verification.

Why "Preview per Branch" Fixes It

A preview environment is a live, isolated instance of your app deployed from a single branch. It gets its own URL. It runs independently of every other branch. When the branch gets merged or the TTL expires, the preview self-destructs.

This changes the review workflow completely. Instead of queuing for staging, every developer — and every reviewer, client, and QA engineer — gets their own URL to click. No coordination. No "is staging free right now?" messages in Slack. No shipping a feature you've only tested on localhost.

For solo developers, preview environments solve a different version of the same problem. You don't have teammates overwriting your staging deploy, but you also don't have anyone else to catch what you missed. A preview URL lets you send a link to a friend, a client, or even just your phone, and see what actually deployed — not what you think deployed.

The Gap Most Tools Leave Open

Vercel and Netlify do preview deployments exceptionally well — for frontend stacks. Push a branch, get a URL. It works every time for Next.js, Nuxt, Astro, or any static site.

The gap is backends. If your app is Django, Rails, Laravel, FastAPI, or Spring Boot, your deploy pipeline doesn't fit the serverless model. You can't deploy a Django API to Vercel without contorting it into serverless functions. You can't get a Netlify preview URL for a Rails monolith that needs a database migration on deploy.

The tools that do handle backend previews — Railway, Render, Northflank — charge per-second or per-resource. The meter starts when the container spins up and stops when you remember to tear it down. Forget to shut down three previews over a weekend, and the bill follows you into Monday.

Preview environments should be dead simple: push a branch, get a URL, share it. The complexity — the YAML, the billing math, the manual teardown — should vanish.

What PreviewDrop Does Differently

PreviewDrop is built for the "any Docker app" gap. Django, Rails, Laravel, FastAPI, Spring Boot — if it runs in Docker, PreviewDrop previews it. No serverless adapter. No YAML manifests. No per-second billing.

The setup is one command:

npx previewdrop setup

That command detects your framework, writes a GitHub Actions workflow file, and prints the one secret to add to your repo settings. Push a branch, and PreviewDrop builds your container and posts a live HTTPS URL — either as a commit status check on a PR, or to your dashboard for any tracked branch.

The URL includes a QR code for mobile testing, optional password protection, and an auto-expiring TTL. It self-destructs when the timer runs out. No zombie containers. No leftover URLs. No "oh no I left a preview running for three weeks" bill.

Pricing is flat per workspace. Starter is $19/month for 5 concurrent previews and 3 team members. No per-seat math. No compute overages. The same $19 whether your team has two PRs open or ten.

Why Solo Developers Should Care

If you're a solo developer, you might wonder why any of this matters. You don't have teammates stomping on your staging environment. You don't have coordination overhead.

But you do have clients. You do have side projects you show to friends. You do have moments where you ship something you've only tested on your own machine, in your own browser, with your own environment variables.

A preview URL costs you nothing on the free plan — two concurrent previews, three projects, no credit card required. It turns "trust me, it works on my machine" into "here's a link, check it yourself."

That's a credibility upgrade that costs five minutes to set up.

The May 20th Launch

PreviewDrop launches on Product Hunt on May 20, 2026. If you want early access, a launch-week discount, and a free-tier setup guide for your specific stack, drop your email at previewdrop.dev — the "notify me on launch" form is at the bottom of the page.

No spam. One email the morning we go live, plus the setup guide. Unsubscribe whenever.

Stop merging blind. Get a live URL for every branch, for every project, from day one.

PreviewDrop's Privacy Policy Is Live — What It Means for Teams Who Care About Data

Cristian Iridon — Sat, 25 Apr 2026 19:44:07 +0000

When your team evaluates a new developer tool, the conversation rarely starts with the privacy policy. It starts with the demo, the pricing page, the GitHub integration, and whether the CLI actually works the first time. Privacy comes later — usually surfaced by a security-conscious engineer, a cautious engineering manager, or the procurement process that kicks in once the tool starts touching production infrastructure. Today, that conversation gets easier. PreviewDrop's /privacy page is live as of April 7, 2026, and it's built to answer the questions your team will eventually ask before they ever need to ask them.

The Trust Gap in Developer Tooling

There's a peculiar problem in the developer tooling market. Most tools in this space — ephemeral preview environments, CI/CD integrations, deployment orchestration platforms — are built by engineers for engineers. The technical quality is often excellent. The legal and compliance infrastructure lags years behind.

That gap creates friction at exactly the wrong moment: when a team is ready to scale adoption. An individual developer can spin up PreviewDrop and start using it in an afternoon. Getting it approved for a 20-person engineering team at a company with any kind of procurement process is a different matter. Legal needs to sign off. Security wants to know where data lives. The CTO wants to understand what access the GitHub OAuth integration actually grants.

The trust gap is real, and it costs adoption. Tools that close that gap early — by shipping clear privacy policies, terms of service, and security documentation before they're forced to by compliance requirements — earn the trust of teams that would otherwise wait months before expanding usage.

What the Policy Covers

PreviewDrop's privacy policy is organized into nine sections, each addressing a specific aspect of how the platform handles your data:

Data collected: account info, GitHub integration details, usage data, technical identifiers
How it's used: operating the service, product communications, usage analysis, billing — and explicitly NOT sold to advertisers or shared with unrelated third parties
Data retention: data is not kept longer than necessary to operate the service
Your rights: clear contact pathway to exercise data subject rights

Why Ephemeral Environments Have a Unique Data Question

Ephemeral preview environments have a particular data characteristic that distinguishes them from most SaaS tools: they're designed to be temporary. A preview environment spins up for a pull request, hosts a running version of your application, and then gets torn down when the PR is merged or closed.

What happens to your environment configuration when the environment is destroyed? If your preview environment touched environment variables — API keys, database credentials, service tokens — where do those values live in the platform's infrastructure, and for how long?

PreviewDrop's policy addresses this directly: the ephemerality of the environments extends to the data practices surrounding them.

A Practical Checklist for Teams Evaluating PreviewDrop

Terms of Service at /terms — Effective April 7, 2026
Privacy Policy at /privacy — Nine sections, structured for readability. Effective April 7, 2026
GitHub OAuth Scope — Documented in the data collection section
Contact pathway — Direct route to the PreviewDrop team for compliance questions

Head to previewdrop.com to create your account. The product is ready. The policy is live.

PreviewDrop Just Became a Serious Team Tool

Cristian Iridon — Sat, 25 Apr 2026 19:43:39 +0000

There's a moment in the lifecycle of every developer tool when it stops being something a single engineer uses for convenience and becomes something an entire team depends on. That transition doesn't happen automatically. It requires the tool to earn it — to add the features that make individual productivity possible for whole teams, not just the person who discovered the tool first. As of April 7, 2026, PreviewDrop has taken a significant step toward that threshold.

Two features are now live in every project's settings page: a full environment variables editor and an auto-preview toggle. They sound like incremental additions. They're not. Together, they fundamentally change what PreviewDrop can do for a team — and they directly address the two most common reasons teams hesitate to expand their use of ephemeral preview environments beyond individual experiments.

If you've been using PreviewDrop for your own branches but haven't pushed it to your wider team, this is the moment to reconsider.

Why Teams Stall on Preview Environments

Ask an engineering manager why their team doesn't use ephemeral preview environments for every pull request, and you'll almost always get a variation of the same two answers. First: "the previews don't have the right config, so they're broken half the time." Second: "our team doesn't need an automated preview on every branch — it creates noise, and people stop paying attention."

Both of these are legitimate operational concerns, not criticisms of the concept. Preview environments work. But preview environments without configuration management produce previews that are only half-working, and teams that can't control when previews spin up end up drowning in preview URLs that nobody asked for.

The env vars editor and auto-preview toggle exist precisely to solve these two concerns. The first gives your team the ability to define the configuration that makes a preview actually run. The second gives your team control over when previews are triggered at all. These aren't cosmetic features — they're the features that turn a useful tool into a dependable part of your workflow.

Environment Variables: The Feature That Makes Previews Real

Here's what happens on a team without environment variables support in their preview tool. A developer opens a pull request. A preview environment spins up. Another developer — or a product manager, or a designer — opens the preview URL to review the changes. The app loads but looks wrong. Or throws an error. Or shows no data at all. Because the preview is running without the API key that connects it to the backend, without the feature flag that enables the new UI, without the database URL that populates the page.

That moment — the moment when a stakeholder opens a preview link and sees a broken experience — erodes trust in the entire preview workflow. It trains people to expect that preview links don't quite work. It makes code reviewers stop using previews for visual verification. It defeats the entire purpose of running ephemeral environments in the first place.

Environment variables are the missing piece that makes preview environments trustworthy.

With the env vars editor in PreviewDrop's project settings, your team defines the configuration once at the project level. Every preview environment that spins up from that project inherits those variables automatically. You add a key-value pair for NEXT_PUBLIC_API_URL, and every preview knows where to find the API. You add your feature flag base URL, and every preview can toggle features correctly. You add the connection string to a preview database, and every preview has real data to display.

The editor is built for team use, not just individual configuration. Values are masked by default — a developer who has access to the project settings page cannot accidentally expose a secret to someone looking over their shoulder. Individual values can be revealed and hidden per row, giving you inspection capability without permanent exposure. Duplicate key validation prevents a common class of configuration error before it reaches the API. And the entire set of variables is saved atomically — there's no state where half your changes are in and half are out.

Auto-Preview Toggle: Give Your Team Back Control

The auto-preview toggle in project settings is a single on/off control that determines whether PreviewDrop automatically creates a preview environment every time a new branch is pushed to the connected repository.

Teams with active repositories know the problem this solves. When auto-preview is always on, every branch generates a preview — including the branch a developer opened to test a one-line config change, the branch that's three commits deep on a weekend experiment, and the branch that's been open for six weeks and hasn't been touched. The preview list becomes unmanageable. Notifications become noise. Developers start ignoring them.

With the auto-preview toggle, that choice belongs to your team, not to the tool. Flip it off, and previews are only created when someone explicitly triggers them. Flip it on, and every branch gets a preview automatically. The setting persists at the project level, so you set it once and the behavior is consistent across your entire team's workflow.

What This Means for Team Adoption

Environment variables answer the "will the previews actually work?" question. Auto-preview answers the "will this create too much noise?" question. Together, they remove the two most common objections before they surface in a team discussion.

If you're an engineering manager who has been waiting for PreviewDrop to reach a certain level of maturity before proposing it to your team, today marks that milestone.

Start building with PreviewDrop today → previewdrop.com