The best StackBlitz alternatives in 2026

StackBlitz is the odd one out in every shortlist it appears on. Put it next to CodeSandbox, Gitpod, Codespaces and Replit and it looks like a peer product with a different logo. It is not. The other four rent you a computer somewhere and stream you a view of it. StackBlitz does not rent you anything, because there is no computer. Your code runs inside the browser tab you already have open, on a Node runtime compiled to WebAssembly.

That single architectural decision explains everything people love about StackBlitz and everything that eventually makes them go looking for an alternative. It is why a project opens in about the time it takes a page to paint. It is why the company does not have to pay for a Linux box for every reader of your documentation. It is also why you cannot install a native module, cannot run Postgres next to your app, cannot run Python, and cannot leave anything running after the tab closes.

So "StackBlitz alternatives" is a badly-formed question until you answer a prior one: what were you using it for? The answer splits four ways, and the four shortlists barely overlap. I build PandaStack, a Firecracker microVM platform, which is a serious candidate for exactly one of those four jobs and an actively bad idea for another one. I will say which is which.

What StackBlitz actually is, stated precisely

StackBlitz's runtime is WebContainers: an operating-system-shaped environment implemented in WebAssembly and JavaScript that runs inside the browser's own sandbox. It gives you a virtual filesystem, a Node-compatible runtime, a package manager that resolves against the public registry, and a local HTTP server whose output is piped straight into an iframe next to your editor. No bytes of your code ever have to reach a server for it to run.

It is worth pausing on how unusual that is. Every other product in this comparison has a machine somewhere with your files on it. The whole engineering discipline of those products is about making that machine appear fast, stay warm, and not cost too much. StackBlitz opted out of the problem entirely by moving the machine into the reader's laptop. The reader pays for the compute, in the sense that their fan spins up, and the vendor pays for approximately nothing.

What that architecture is genuinely brilliant at

• Cold start. There is no VM to schedule, no container to pull, no kernel to boot, no network round trip before the first character of your code executes. Startup is bounded by how fast the browser can fetch and instantiate a WASM bundle, and after the first visit much of that is cached.
• Cost at the top of a funnel. If you put a runnable example on the front page of your framework's docs and it goes to the top of Hacker News, a server-backed playground is a bill and a capacity incident. A browser-backed one is a CDN request.
• Privacy and offline-ish behaviour. The code in the editor is not uploaded to run. For a company evaluating a tool with a snippet of their own source pasted in, that is a real and underrated property. Once loaded, a WebContainer keeps working through a flaky connection, apart from package installs.
• Scale that does not care. One reader or fifty thousand readers cost the operator the same. There is no autoscaler to tune and no p99 to chase, because there is no queue.
• Frontend fidelity. For the specific workload of "a Vite or Next or Angular dev server with hot module reload", it is excellent, and the loop between editing a file and seeing the result is genuinely tighter than a remote environment can be, because there is no network in the loop.

If your use case sits inside that list, do not migrate. Nothing in this article beats it on those axes, and certainly not us. I have written the rest of the post assuming you hit one of the walls below.

And the wall it hits

The constraints are not bugs and they are not going to be fixed by a roadmap, because they follow from the browser being the sandbox. A browser tab is not allowed to execute arbitrary machine code, open raw sockets, or persist a process. So:

• No arbitrary native binaries. If a dependency ships a compiled .node addon, or your build shells out to a Rust or Go binary, or you need ffmpeg, ImageMagick, or a headless Chrome, that is outside what a WASM-compiled Node can do. Some things have WASM ports; most of your transitive dependency tree does not.
• Node-shaped only. The runtime is a Node reimplementation. Python, Ruby, Go, Java, a JVM test harness, a .NET SDK, or a polyglot monorepo are not in scope. This is the single most common reason I see people leave.
• No real database process. You cannot run Postgres, MySQL, Redis or Elasticsearch in a browser tab. In-memory shims and SQLite-compiled-to-WASM cover a surprising amount of teaching material and none of the cases where the point is that your ORM talks to the actual server.
• No raw sockets. Outbound network is what the browser permits, which means HTTP through the page's own fetch semantics and the CORS rules that come with it. Anything speaking a wire protocol over TCP is out.
• Tab lifetime is process lifetime. Close the tab and the machine ceases to exist. There is no background worker, no cron, no long-running job that finishes while you go to lunch, and no way to hand a running environment to a colleague.
• The user's RAM is your RAM. A big monorepo install plus a webpack build plus the editor itself all live in one tab on a laptop you do not control. A machine with 8 GB and thirty other tabs open is a support ticket waiting to happen, and you will never be able to reproduce it.
• Nothing to drive programmatically from a server. There is an embed SDK for driving the editor from a page, but there is no API you call from your backend to get a machine, because there is no machine. For anything where a program, not a person, is the user, this is disqualifying by construction.

I wrote a longer technical head-to-head on this runtime model versus microVMs, if you want the mechanism rather than the shortlist. This post is the shortlist.

The four jobs people are actually replacing StackBlitz for

Before you look at a single vendor, work out which of these you are doing. The right answer for one is close to the worst answer for another.

1. An embeddable playground. Runnable examples inside your documentation, a tutorial series, an interactive changelog, a framework's landing page. The user is a human reader, the session lasts minutes, and the thing that matters most is that the page does not get slow and the example does not get expensive.
2. A cloud development environment for a team. Real work, real repositories, hours-long sessions, an editor with your extensions, a terminal, and state that survives lunch. The user is a developer on your payroll.
3. Programmatic sandboxes driven by a program. An AI agent writing and running code, a code-interpreter feature in your product, user-submitted code you have to execute, an autograder. There is no human in the loop and no UI requirement at all. This is the fastest-growing reason I see people outgrow StackBlitz, and it is the one where StackBlitz was never a candidate in the first place.
4. Builds and tests at scale. You liked that StackBlitz made an environment appear instantly, and you want that property for CI: hundreds of clean environments a day, each one identical, each one thrown away.

Jobs one and two are about a person looking at a screen. Jobs three and four are about a machine calling an API. If you cannot tell which side of that line you are on, you are not ready to pick a vendor yet.

Job one: an embeddable playground for docs and tutorials

This is StackBlitz's home turf and it is genuinely hard to beat. Be honest with yourself about whether you actually need to leave. The reasons that hold up are: your examples are not JavaScript, your examples need a native dependency or a database, or you need to run the exact same code path server-side as well and you are tired of maintaining two versions of every snippet.

Sandpack

Sandpack is CodeSandbox's open-source bundler-and-editor component, published as a React component you drop into your own site. It is the most direct structural competitor to a StackBlitz embed, and the comparison is interesting: Sandpack bundles and executes in the browser too, but through its own bundler rather than a Node reimplementation, which makes it lighter for the common case of a component demo and less capable for the case of a full dev server with a terminal.

The reason to choose it over StackBlitz is usually ownership. It is a component in your repository, it renders inside your own layout with your own theme, it is not an iframe pointed at somebody's domain, and if the vendor's product direction changes your docs do not. The reason not to is that you now own the integration, including the day a React major version lands and your docs build breaks.

• Best for: component libraries, design systems, framework docs, anything where the example is a React or vanilla-JS snippet rather than a whole application.
• Check before committing: bundle size on a page that has three of them, how it behaves with your site's dark mode, whether your examples need a real dev server or just a bundle.

CodeSandbox embeds

The hosted product, embedded as an iframe. CodeSandbox has historically run the heavier end of its workloads on real machines rather than in the tab, which is precisely the tradeoff you are looking for if your example needs something the browser cannot give you. You pay for that with a server round trip and with a vendor whose costs scale with your traffic, which they will price accordingly.

Worth reading my separate breakdown of that product, because CodeSandbox is really two products under one name and the alternatives differ depending on which half you were using.

StackBlitz's own SDK, used differently

The alternative nobody suggests: keep StackBlitz and change how you embed it. If the problem is page weight rather than capability, lazy-load the embed behind a click and render a plain highlighted snippet by default. Most readers of most docs pages never click run, and making all of them download an IDE is a self-inflicted wound that has nothing to do with the vendor.

If the problem is capability, this does not help and you need one of the other options. But check which problem you have first. I have seen at least two teams migrate for performance reasons that were entirely fixed by not mounting the thing on page load.

CodeMirror or Monaco plus a server-side runner

The build-it-yourself option, and it is more reasonable than it sounds. The editor half is solved: CodeMirror 6 is small, accessible and themeable, and Monaco gives you the VS Code editing experience if you can afford the weight. The execution half becomes one HTTPS call to a sandbox API that returns stdout, stderr and an exit code.

This is the pattern you end up at when your examples are Python, or Go, or SQL against a live database, or when a single example needs three languages talking to each other. It is also the only pattern where the code in your docs is executed by exactly the same runtime your users will run it on, which eliminates a whole class of "works in the playground, fails locally" bug reports.

The costs are real and you should name them up front: you are now paying for compute per reader who clicks run, you need rate limiting and abuse handling because a public run button is a free compute endpoint on the internet, and you need the execution to be isolated well enough that an anonymous stranger's code cannot reach anything. That last point is where a hypervisor boundary stops being an architecture preference and becomes a requirement.

Job two: a full cloud development environment for a team

Some teams used StackBlitz as an actual working environment rather than a demo surface, usually for frontend work where the browser runtime is a good fit. When the work grows a backend, a database, or a second language, that stops working and you are shopping in a different category: cloud development environments.

GitHub Codespaces

The default. Your code is probably already on GitHub, your team probably already uses VS Code, and Codespaces reads the devcontainer.json file your repository benefits from having regardless of which vendor you pick. Prebuilds are first-class, which is the feature that decides whether a cloud environment feels fast or feels like punishment on a monorepo.

The tradeoffs are the usual ones for a default: you are on their machines in their regions, and the bill is dominated by idle time rather than usage, because developers start a workspace at nine and leave it running through two meetings and lunch. Evaluate the idle behaviour, not the hourly rate.

Gitpod

Same broad premise, with a heavier historical focus on reproducible prebuilt workspaces and, in its more recent generation, on running inside your own cloud account. If the requirement driving your evaluation came from a security review rather than from developer experience, that matters. I have a fuller writeup of this category if you are choosing between the two.

Coder and DevPod

The self-hosted end. Coder provisions workspaces in your own infrastructure through Terraform templates, so a workspace can be a Kubernetes pod or an EC2 instance in an account your auditors already know about. DevPod runs the devcontainer spec against a provider you choose, including your own laptop, with no platform at all.

Both trade a signup for a project. Someone on your team owns the templates, the base images and the upgrade path. That is the correct trade when source code genuinely cannot leave your account, and an expensive detour when it is a preference.

Replit

Worth naming separately because it is the closest thing to "StackBlitz but with a real machine underneath". You get a full Linux environment, a package manager, ports, a database, deployment, and increasingly a lot of AI-driven authoring on top. If what you wanted from StackBlitz was the zero-setup feel and you are willing to accept a server-backed environment to get more capability, this is the shortest hop, and I have a dedicated comparison of its alternatives too.

Job three: programmatic sandboxes an agent or a backend drives

This is the growth case, and it is the one where the StackBlitz model is not merely limited but structurally inapplicable. A WebContainer exists because a person has a tab open. If your agent runs on a server at three in the morning, there is no tab, no browser, and nothing to run inside.

Teams arrive here from two directions. Some built a feature on a browser playground, then added an AI assistant that needs to execute the code it writes, and discovered the execution has to move server-side. Others were never really doing job one at all: they picked a playground because it was the only "run some code" product they had heard of.

The products in this category are more similar than their marketing implies. Almost all of them will hand you an isolated Linux environment in well under a second, let you write files, run commands, stream output and tear it down. The differences that decide the purchase are narrower and less exciting.

What to actually evaluate

• Isolation boundary. A container with a tight seccomp profile shares a kernel with everything else on the host. A microVM has its own kernel behind a hypervisor. If the code was written by a language model or uploaded by a stranger, this is the whole decision and you should know which one you are buying rather than inferring it from the word "sandbox".
• Creation latency and its tail. A p50 of 200 ms with a p99 of eight seconds is a worse product than a p50 of 400 ms with a p99 of 600 ms, because your users live in the tail. Ask for both, then measure it yourself with a burst of fifty concurrent creates, not one at a time. A lot of platforms look identical at concurrency one.
• Fork semantics, and what the word means to that vendor. Cloning a filesystem copy-on-write so N children skip the dependency install is common. Forking a running process, with a warm interpreter and your data already in memory, is rare and usually constrained. Both get called fork. Ask which one you get.
• Lifetime and cleanup. What happens when your orchestrator dies mid-task? No TTL means you pay for orphans forever; an aggressive one kills legitimate long work. You want a default TTL you can override per sandbox.
• Egress control. Whether you can restrict what the sandbox reaches. For untrusted code, unrestricted outbound turns your sandbox into an open proxy on someone else's behalf, and you will find out about it from an abuse report.
• Persistence and statefulness. Whether anything survives between sessions, and at what granularity: a volume, a snapshot, or nothing at all.
• What lives next to the sandbox. If the agent's task is "build a small app", it will want a database and somewhere to serve from. Whether that is one vendor or four is a real operational difference.

E2B

The most established sandbox API aimed at agent workloads, with mature Python and TypeScript SDKs, a code-interpreter-shaped abstraction, and a large body of published examples. It is the sensible baseline: pick it first, benchmark everything else against it, and if nothing beats it on your specific workload you have your answer cheaply.

Daytona

Development-environment lineage repointed at agent workloads, with a focus on fast creation and declarative environment definitions. If your mental model of a sandbox is closer to "a dev environment a program drives" than to "a function invocation", the shape of it will feel natural.

Modal

Not a sandbox product first. Modal is a serverless compute platform with a strong Python-native programming model, and its sandbox primitive is one capability among several. Choose it when execution is one stage of a larger compute pipeline, particularly when GPUs or heavy Python dependency trees are involved, because that is the adjacent problem it is exceptionally good at.

Runloop, Vercel Sandbox, Cloudflare, Fly Machines

• Runloop is purpose-built for coding agents, with devbox-shaped environments and snapshotting aimed at long agent sessions.
• Vercel Sandbox is ephemeral compute inside the Vercel platform, which is the natural choice if the calling app already lives there and you want one vendor and one invoice.
• Cloudflare's sandbox and container offerings give you very low latency and a global footprint, with the runtime constraints that come from that architecture. Excellent for short self-contained execution; check compatibility carefully for anything wanting a full Linux userland.
• Fly Machines is not a sandbox product, it is a VM API. More assembly required, and in exchange complete control over the image and the network.

PandaStack

This is my product, so read it with that in mind. PandaStack gives you a Firecracker microVM from an API call. Every create restores a baked memory snapshot rather than cold-booting a kernel, which is where the numbers come from: p50 create latency is around 179 ms in production. Each sandbox gets its own guest kernel and its own network namespace, so the boundary is KVM, not a shared kernel with a policy on top.

Three things are specifically relevant to somebody arriving from StackBlitz:

• It is real Linux, so the entire class of "the browser cannot do that" problems disappears at once. Native modules, ffmpeg, a compiler toolchain, Python and Go and Java side by side, a background process that outlives the request.
• Fork clones a prepared sandbox copy-on-write, memory plus an XFS reflink of the disk, in roughly 400 to 750 ms on the same host. Install your dependencies once, then branch that state N times. For an agent trying five approaches in parallel, that is one dependency install instead of five.
• Managed Postgres with branching and point-in-time restore, git-driven app hosting, and serverless functions with cron sit on the same substrate. If the agent's job is "build a thing and show me the thing", the database and the URL are in the same account rather than in three other vendors.

Idle sandboxes scale to zero, which matters for the agent workload shape specifically: a long tail of environments that exist for eleven seconds and a small number that exist for hours. Python and TypeScript SDKs are on PyPI as pandastack and on npm as @pandastack/sdk.

Where we are the wrong answer, plainly: there is no editor, no embed, no iframe, no in-page UI. If you came here wanting a runnable example on a docs page, we are not competing for that job and StackBlitz is better at it than anything I could build. We are also the wrong answer if what you want is a workspace a human types into all day, which is Codespaces' job, and overkill if your execution is genuinely thirty milliseconds of pure JavaScript with no filesystem, which an isolate-based runtime does more cheaply.

The same job, done as an API call

Here is the concrete version of the thing StackBlitz cannot do: take a snippet that arrived from a user or a model, run it on a real machine, get the output back, and destroy the machine. No tab required.

from pandastack import Sandbox

SNIPPET = '''
import platform, subprocess, sys
print(platform.platform())                    # a real kernel, not a WASM shim
print(sys.version)                            # Python, which a browser tab cannot run
subprocess.run(["ffmpeg", "-version"], check=False)   # a real native binary
'''

# Every create restores a snapshot instead of cold-booting: p50 ~179ms.
sbx = Sandbox.create(
    template="code-interpreter",
    ttl_seconds=300,          # ALWAYS set one. If your orchestrator crashes,
)                             # this is the thing that stops the bill.

try:
    sbx.filesystem.write("/work/snippet.py", SNIPPET)
    r = sbx.exec("python3 /work/snippet.py", timeout_seconds=60)
    print(r.exit_code)
    print(r.stdout)
    print(r.stderr)
finally:
    sbx.kill()

The interesting part is not that line-for-line it looks like every other sandbox SDK in the category, because it does; a migration between any two of them is mostly renaming. The interesting part is what you can do after the environment exists. Install once, snapshot, then branch:

from pandastack import Sandbox

# Pay for the expensive setup exactly once.
parent = Sandbox.create(template="code-interpreter", ttl_seconds=3600)
parent.exec("pip install -q pandas pyarrow scikit-learn", timeout_seconds=600)

# Branch it. Children inherit the parent's disk copy-on-write -- installed
# packages, written files -- and come up in roughly 400-750ms on the same host.
children = parent.fork_tree(5)

for i, child in enumerate(children):
    out = child.exec(f"python3 /work/strategy_{i}.py", timeout_seconds=120)
    print(i, out.exit_code, out.stdout[-400:])

for child in children:
    child.kill()
parent.kill()

And the TypeScript equivalent, including the preview URL, which is the closest thing we have to the iframe you get from a browser playground. It is a real HTTP endpoint served from a real process in the VM, not an in-page render, so it works for a Django app or a Go binary just as well as for Vite.

import { Sandbox } from "@pandastack/sdk";

const sbx = await Sandbox.create({ template: "base", ttlSeconds: 900 });

try {
  await sbx.filesystem.write("/work/server.js", `
    const http = require("http");
    http.createServer((_, res) => res.end("hello from a real kernel"))
        .listen(3000, "0.0.0.0");
  `);

  // A real background process. It survives the request that started it,
  // which is the specific thing a browser tab cannot promise you.
  await sbx.exec("setsid node /work/server.js > /var/log/app.log 2>&1 &");

  // Tokenless preview URL: https://3000-<sandbox-id>.<suffix>
  // The sandbox UUID is the credential, and it lives as long as the sandbox.
  console.log(sbx.previewUrl(3000));

  const health = await sbx.exec("curl -sS -o /dev/null -w '%{http_code}' localhost:3000");
  console.log("health:", health.stdout.trim());
} finally {
  await sbx.kill();
}

Job four: builds and tests at scale

If what you admired about StackBlitz was that an environment appeared instantly and was thrown away afterwards, and you now want that property for your CI, you are shopping for ephemeral compute rather than for a playground. The relevant properties change again.

• Cache restore, not create latency. A runner that starts in three seconds and then spends four minutes on a cold npm ci is slower than one that starts in thirty seconds from a snapshot taken after install. Time the whole path from trigger to green, and ignore every marketing number about provisioning speed.
• Concurrency behaviour, not single-job speed. Your pain is at 09:15 on Monday when forty pull requests all get pushed. Measure the fortieth job, not the first.
• Isolation between jobs. Shared runners with a shared Docker daemon leak state between builds, and the resulting flakes are the hardest class of CI bug to debug because they are not reproducible in isolation.
• Whether you can snapshot after setup. This is the generalisation of Gitpod's prebuild idea, and it is the single biggest lever on perceived CI speed for a heavy monorepo.

The candidates are self-hosted GitHub Actions runners on your own machines, Buildkite-style agent models where you own the compute, Depot and similar build-acceleration products, and microVM-backed runner fleets including ours. Snapshot-restore is the reason a microVM makes sense here: you get a fresh kernel per job with none of the per-job boot cost that historically made VMs unattractive for CI.

The hybrid pattern, which is usually the right answer

Most teams that ask me this question do not need to replace StackBlitz. They need to stop asking it to do a second job it was never designed for. The pattern that works looks like this.

1. Keep the browser playground for the happy path. Ninety percent of your examples are a component, a hook, a config file, a small JavaScript function. Those run beautifully in a tab, cost you nothing, and start instantly. Do not move them.
2. Add a server-side runner for the examples that need one. Python examples, examples that hit a real Postgres, examples that need a native binary, examples that demonstrate your CLI. Same editor component on the page, different execute button behind it.
3. Route by example, not by page. A frontmatter flag in your docs source that says which runtime an example needs, so the decision is per-snippet and the reader never sees the seam.
4. Rate-limit and isolate the server-side path hard. It is a public compute endpoint. Cap wall-clock time, cap memory, restrict egress, and use a VM boundary rather than a container, because the people who find a free execution endpoint are not all curious.
5. Use the same execution path for your own CI. If the runner that executes your docs examples is the same one that runs them in CI, your examples cannot silently rot. This is the actual payoff of the hybrid model and the reason I recommend it over picking one runtime for everything.

The failure mode on the other side is worth naming too. Do not move every example server-side because three of them needed it. You will turn a free, instant, infinitely scalable thing into a bill with a p99.

What leaving actually costs

For the embed case, most of the work is content, not code. Swapping StackBlitz for Sandpack is a component change; rewriting sixty examples so they work in a different bundler with different module resolution is three weeks nobody scheduled.

For the API case, the mechanical port is a day, because every product in the category exposes the same five operations: create, write file, run command, read output, destroy. The parts that take longer:

• The base image. Your code assumes a set of installed packages and the new platform's default differs. Build your own template with pinned dependencies rather than relying on what happens to be there. You needed to do this anyway; the migration is just when you find out.
• Streaming. Blocking exec ports trivially. Streaming stdout is where the protocols diverge -- server-sent events, WebSocket, long-poll -- and if your UI shows live output, this is the real work.
• Timeout and retry behaviour. Your error handling is tuned to one platform's specific failure vocabulary. Every platform fails differently under load. Expect to rewrite the retries and expect the first week in production to teach you something.
• Cost shape. Per-second, per-invocation and reserved-capacity billing produce wildly different bills for the same workload. Model your actual usage pattern, especially the ratio of very short sandboxes to long ones, rather than comparing headline rates.
• Concurrency limits. Almost every platform has one, it is frequently not on the pricing page, and it is the thing that will page you during your first traffic spike. Ask before you sign, not after.

Pick by situation

• Runnable JavaScript examples in your documentation, and you care about page weight and cost -> stay on StackBlitz, lazy-load the embed behind a click. If you want the component in your own repo instead of an iframe, Sandpack.
• Examples that are not JavaScript, or need a native binary or a real database -> your own editor component plus a server-side runner behind it. CodeMirror or Monaco for the editor, a sandbox API for execution.
• A real working environment for developers on your team -> GitHub Codespaces if you are on GitHub and in VS Code, Gitpod or Coder if the requirement came from a security review, DevPod if you want the devcontainer without a platform.
• A StackBlitz-like zero-setup feel but with a real machine underneath -> Replit is the shortest hop.
• An AI agent that executes the code it writes -> a sandbox API with a hypervisor boundary. E2B as the baseline to benchmark against, PandaStack if you need fast copy-on-write forking or a database and a deploy target next to the sandbox, Modal if the work is GPU-shaped or sits inside a bigger Python pipeline.
• User-submitted code from strangers -> the isolation model is the entire decision. Insist on a VM boundary and egress control, and treat container-only isolation as unsuitable no matter how good the seccomp profile is.
• Ephemeral CI at volume -> microVM runners with snapshot-after-setup, and measure the fortieth concurrent job rather than the first.
• You just want your docs examples to stop diverging from reality -> run them in CI on the same runtime the reader gets. That is a process fix, not a vendor change, and it is worth more than either.

The short version

StackBlitz is not a slightly different CodeSandbox. It is a bet that the best place to run a code example is the reader's own browser, and for the specific job of a fast, cheap, private, instantly-starting JavaScript playground, that bet is correct and nothing in this article beats it.

You leave when the code stops being JavaScript, when it needs a binary or a database or a real kernel, when it has to keep running after the tab closes, or when the thing driving it is a program rather than a person. Those are four different exits and they lead to four different products. Sandpack and a self-hosted editor for embeds. Codespaces, Gitpod or Coder for team environments. A sandbox API with a hypervisor boundary for agents. MicroVM runners for CI.

The advice that survives whichever way you go: work out whether a human or a program is the user before you shop, benchmark the tail rather than the median, know exactly what your isolation boundary is, and set a TTL on everything you create. Those four habits matter more than the vendor, and they make the next migration a day of work instead of a quarter.