How to Set Up Cloud Dev Environments That Spin Up in Seconds

Every developer has been there.

New team member joins. Spends the first two days fighting with their local setup. Wrong Node version. Missing system library. Database won't start. Docker conflicts with something else. The README says "it should just work on macOS" but they're on Linux.

Or worse: your local environment works, but your colleague's doesn't. Same repo, same branch, different results. "Works on my machine" becomes a daily conversation.

Cloud dev environments fix this. Instead of running code on your laptop, you run it on a cloud server that's pre-configured, reproducible, and disposable. Everyone gets the exact same environment. It spins up in seconds, not hours.

Here's how to set this up properly.

What a good cloud dev environment looks like

A cloud dev environment that developers actually want to use needs:

• Instant startup - Nobody will use it if it takes 5 minutes to boot. It needs to be ready in seconds.
• Full Linux environment - Not a limited sandbox. A real terminal, real filesystem, real networking. Developers need to install packages, run servers, use debuggers.
• Persistence - Your code, installed packages, terminal history, and configuration survive across sessions. You pick up where you left off.
• Isolation - One developer's environment can't interfere with another's. Installing a broken package or crashing a service stays contained.
• Connectivity - Port forwarding for dev servers. SSH access for editor integration. HTTPS URLs for sharing previews.
• Reproducibility - Every developer gets the same starting point. Same OS, same tools, same versions.

Setting it up with Oblien

Step 1: Define your base image

Oblien workspaces run from Docker images, so you can use any public or custom image. For most web development:

• node-22 - Node.js 22 with npm, common build tools
• python-3.13 - Python 3.13 with pip
• go-1.22 - Go 1.22 with standard toolchain
• ubuntu-24 - Clean Ubuntu for custom setups

Or build a custom image with your team's exact toolchain:

FROM node:22
RUN apt-get update && apt-get install -y \
  git curl vim ripgrep \
  postgresql-client redis-tools
RUN npm install -g typescript eslint prettier

Push it to a registry, and every workspace boots with your exact tool stack.

Step 2: Create developer workspaces

From the Oblien dashboard, create a workspace for each developer:

• Image: Your custom dev image (or a standard one)
• CPU: 4 cores (comfortable for builds and dev servers)
• Memory: 8 GB (enough for Node.js, bundlers, and a database)
• Disk: 20 GB (repos, node_modules, build artifacts)

The workspace boots in ~130ms. Your developer has a full Linux VM with everything they need.

Step 3: Clone and start working

Open the terminal from the dashboard:

git clone git@github.com:your-org/your-project.git
cd your-project
npm install
npm run dev

The dev server starts on port 3000 inside the workspace. Click "Expose Port" in the dashboard, and you get an HTTPS preview URL instantly:

https://abc123.preview.oblien.com

Share that URL with a designer, a PM, or a client. No ngrok, no tunnels, no local configuration.

Step 4: Connect your editor

Developers don't want to code in a browser terminal for everything. Connect your favorite editor via SSH:

VS Code:

1. Enable SSH on the workspace (one click in the dashboard)
2. Install the "Remote - SSH" extension
3. Connect to root@your-workspace-id with proxy jump through ssh.oblien.com

You're now editing files in the cloud workspace, running the terminal in the cloud workspace, but your editor is local. Best of both worlds.

Vim/Neovim, Emacs, JetBrains: SSH in directly and use your editor of choice. Your dotfiles persist on the workspace's disk.

Making environments reproducible

The key to reproducibility is making sure every developer starts from the same base:

Snapshot templates

Set up a workspace exactly the way you want - install all dependencies, configure the environment, clone the repo, run npm install. Then take a snapshot.

New developers get a workspace restored from that snapshot. They don't wait for npm install. They don't fight with configuration. They're instantly in a working environment that matches the rest of the team.

Environment as code

Store workspace configuration in your repo:

{
  "image": "your-org/dev-image:latest",
  "cpus": 4,
  "memory_mb": 8192,
  "writable_size_mb": 20480,
  "env": {
    "NODE_ENV": "development",
    "DATABASE_URL": "postgres://..."
  }
}

When the project changes (new dependency, new tool, new environment variable), update the config and documentation. New workspaces pick up the changes automatically.

Handling databases and services

Most projects need a database, a cache, or other services during development. You have two options:

Option A: Run everything in one workspace

For simple setups, install Postgres, Redis, and your app in the same workspace. This is the easiest approach and works for most projects:

apt-get install -y postgresql redis-server
service postgresql start
service redis-server start
npm run dev

Option B: Separate service workspaces

For more complex setups (or when you want production-like isolation), run each service in its own workspace and connect them with private links:

• Dev workspace - Your code and dev server
• Database workspace - Postgres with persistent data
• Cache workspace - Redis for sessions/caching

Connect them with private networking. Your dev workspace can reach the database on its internal IP, but nothing else can. This mirrors production networking and catches configuration bugs early.

Team workflow

New developer onboarding

1. Developer creates a workspace from the team's base image (or snapshot)
2. Clones the repo
3. Runs the setup script
4. Done. Full development environment in under a minute.

No more two-day onboarding for environment setup.

PR previews

Each PR gets its own workspace. The CI creates a temporary workspace, deploys the PR branch, exposes the dev server, and posts the preview URL to the PR. Reviewers see the running app, not just the code diff.

When the PR is merged or closed, the workspace is automatically destroyed.

Experiment freely

Want to try a risky refactor? A new package that might break things? A database migration you're not sure about?

Do it in your workspace. If it goes wrong, you can:

• Restore from your last snapshot
• Or just destroy the workspace and create a fresh one

There's no risk to your local machine, no risk to your colleagues' environments, and no cleanup needed.

Cloud dev environments vs. local development

When to keep developing locally

Cloud dev environments aren't for everyone:

• Offline work - If you frequently work without internet (planes, remote areas), local is your only option.
• GPU development - If you need a local GPU for ML training or graphics work, cloud GPUs add cost and latency.
• Extreme latency sensitivity - If every millisecond of editor lag bothers you, local is faster. Though with SSH + modern editors, most developers can't tell the difference.
• Very small projects - If your setup is npm install && npm start and it works on every machine, the cloud adds unnecessary complexity.

For everything else - team projects, complex toolchains, multi-service architectures, onboarding new developers - cloud dev environments save hours per week.

Getting started

1. Pick your base image - Start with a standard one (node-22, python-3.13) or build a custom Docker image
2. Create a workspace - 130ms to a full Linux VM
3. Clone and configure - Set up your project once
4. Take a snapshot - This becomes your team's starting point
5. Share preview URLs - Expose ports for instant HTTPS previews
6. Connect via SSH - Use your local editor with cloud compute

The goal is simple: zero time spent on environment setup, more time spent building.

Start building now →