Northflank Blog

How to give coding agents ephemeral development environments

2026-10-02T15:15:00.000Z

## TL;DR: how to give coding agents ephemeral development environments - An ephemeral development environment is created for a single task and can be deleted when the task is done. For coding agents, that means every task starts from a clean workspace with the repository at a known commit, the tools the agent needs, and only the credentials that task requires. - Ephemeral environments prevent agents from inheriting leftover files, stale dependencies, old credentials, and side effects from earlier tasks. They also limit what a misbehaving agent can affect and make it easier to run tasks in parallel. - [Northflank Cloud Harnesses](https://northflank.com/docs/v1/application/cloud-harness/quickstart) provide the infrastructure to run coding agents in ephemeral development environments in the cloud. They support Claude Code, Codex, Cursor, OpenCode, Pi, and Bring Your Own Agent. Harnesses run on [Northflank's managed cloud](https://northflank.com/features/managed-cloud) or in your own cloud through [self-serve BYOC](https://northflank.com/features/bring-your-own-cloud), with microVM isolation, configurable compute and networking, and SSH access. Teams can also collaborate across Harnesses and see what other members are working on in real time. > Give your coding agents a fresh environment for every task with [Northflank Cloud Harnesses](https://app.northflank.com/signup), or [book a demo](https://cal.com/northflank/demo) to discuss your setup. > A coding agent that reuses the same environment across tasks can accumulate state over time. Dependencies installed for one task remain for the next, files from abandoned branches stay on disk, and credentials added for previous tasks remain accessible. Each new task starts from an environment whose state is harder to understand, making agent output more difficult to reproduce and trust. Ephemeral development environments solve this by giving each task its own isolated workspace, with the tools, dependencies, and access it needs. This guide covers what ephemeral development environments are, why coding agents benefit from them, how to set them up locally, and how to give coding agents ephemeral environments with Northflank Cloud Harnesses. ## What is an ephemeral development environment? An ephemeral development environment is a development workspace created for a specific task and removed when it is no longer needed. It starts from a known state: a defined base image or toolchain, the repository at a specific commit or branch, and the configuration and secrets the task needs. Once the work is complete and the required outputs have been saved, the environment can be deleted along with its temporary files and resources. A persistent development environment works differently. It is created once and reused across multiple tasks, retaining its files, installed packages, and configuration between sessions. | | Ephemeral environment | Persistent environment | | --- | --- | --- | | Lifecycle | Created for a task and removed when no longer needed | Created once and reused across tasks | | Starting state | Starts from a known configuration | Retains state from previous sessions | | Leftover files and packages | Removed when the environment is deleted | Can accumulate over time | | Credentials | Can be scoped to the current task | May remain configured between tasks | | Reproducibility | Easier to reproduce from a defined configuration | Results can depend on previous changes | | Resource usage | Resources can be released after the task | Resources may remain allocated between tasks | | Best for | Agent tasks, pull requests, and experiments | Long-running development and ongoing workspaces | > For a broader look at short-lived execution environments for AI agents, see [Ephemeral execution environments for AI agents](https://northflank.com/blog/ephemeral-execution-environments-ai-agents). > ## Why give coding agents ephemeral development environments? Giving coding agents ephemeral development environments ensures every task starts from a clean, known state. The agent gets the repository at a specific commit, the required dependencies, and the tools it needs without inheriting leftover files, stale packages, or configuration changes from previous tasks. Ephemeral environments also prevent tasks from interfering with each other. An agent can install packages, modify files, or run commands without affecting another agent's workspace or your local machine. This makes it easier to run multiple agents in parallel, with each working in its own environment. If something goes wrong, such as a destructive command or unexpected script execution, the impact is limited to that environment. Starting from a consistent configuration also makes it easier to reproduce failures and investigate unexpected results. They also make credentials easier to manage. You can provide each task with only the secrets and permissions it needs, rather than reusing credentials across unrelated workloads. Once the task is complete and its outputs are saved, deleting the environment removes its temporary files and releases its resources. ## What should an ephemeral environment for a coding agent include? An ephemeral environment needs the repository, tools, resources, and access required for the agent to complete its task. | Component | What it provides | | --- | --- | | Repository at a known commit | Gives the agent a consistent starting point and a separate branch for its changes | | Development tools and agent CLI | Provides the language runtime, package manager, build tools, test runner, and coding agent | | Scoped credentials | Gives the agent access to the model provider, Git repository, and services required for the task | | Isolation | Keeps the agent's files, processes, and execution separate from other workloads | | Configurable compute | Provides enough CPU, memory, and storage for the task | | Lifecycle management | Allows the environment to be created, paused, resumed, and deleted when no longer needed | Northflank Cloud Harnesses bring these components together in a cloud workspace for coding agents. Each Harness can connect to a Git repository, comes with a pre-installed agent CLI and configurable compute, and runs in an isolated microVM. You can also inject credentials as environment variables and manage the Harness throughout the task lifecycle. ## How to give coding agents ephemeral environments locally A common way to create ephemeral development environments locally is to combine Git worktrees with Docker containers. The worktree gives each task its own directory and branch, while the container provides an isolated execution environment that can be removed when the task is complete. For example, you can create a worktree for a task and start a temporary container with the project's files mounted into it: ```bash # From your main repository git worktree add ../task-142 -b task-142 # Start a temporary container with the task's files mounted docker run --rm -it \ -v "$(pwd)/../task-142:/workspace" \ -w /workspace \ -e ANTHROPIC_API_KEY \ node:22 bash # Inside the container npm install -g @anthropic-ai/claude-code claude ``` Make sure `ANTHROPIC_API_KEY` is already exported in your local shell before starting the container. The `--rm` flag removes the container when you exit, while the mounted worktree remains on your machine. You can also use development containers with a `devcontainer.json` file to define your project's development environment, including its image, tools, and setup steps. When the task is complete, commit and push the agent's changes to the task branch. Once the branch is pushed, remove the worktree: ```bash git worktree remove ../task-142 ``` ## What breaks with local and container-based ephemeral environments? Local containers give each task a separate filesystem, but they still run on your machine and share its kernel, resources, and uptime. This creates limitations when you run several agents, delegate longer tasks, or need stronger isolation. | Problem | What happens locally | On Northflank Cloud Harnesses | | --- | --- | --- | | Isolation | Containers share the host kernel and depend on their configuration for isolation | Each Harness runs in its own microVM | | Setup per task | Tools and agent CLIs may need to be installed in every new container | Supported agent CLIs are available in Harness environments | | Credentials | API keys and other secrets need to be passed into each container | Secrets can be configured for each Harness | | Compute | Containers share your laptop's CPU and memory | Each Harness has configurable compute resources | | Uptime | Local workloads depend on your machine staying available | Harnesses run in the cloud independently of your laptop | | Team access | Other developers need access to your machine to inspect the environment | Team members can access Harnesses to review or continue work | | Cleanup | Worktrees, images, and volumes need to be managed separately | Files and agent sign-ins are cleared on stops, restarts, or redeploys unless persistence is enabled. Harnesses can also be deleted. | Local containers work well for short tasks that you supervise directly. They become harder to manage when agents run unattended, several tasks run simultaneously, or you need to manage credentials and infrastructure across a team. In those cases, cloud-hosted environments can take care of provisioning, isolation, and lifecycle management without relying on a developer's machine. ## How do Northflank Cloud Harnesses give coding agents ephemeral development environments? Northflank Cloud Harnesses are cloud workspaces built for coding agents. Each Harness is configured for one agent at creation, whether Claude Code, Codex, Cursor, OpenCode, Pi, or Bring Your Own Agent, with the agent CLI pre-installed and its credentials injected as environment variables. A Harness can clone a connected Git repository and branch on start, and you can access it through the web terminal in the Northflank dashboard or over SSH from your local terminal. ![image.png](https://assets.northflank.com/image_6ad9a279b4.png) To use a Harness as an ephemeral environment, leave workspace persistence disabled. This gives the agent a temporary workspace for the task, with files and agent sign-ins cleared when the Harness stops, restarts, or redeploys. Once the agent’s work has been pushed to Git, you can delete the Harness when it is no longer needed. Harness lifecycle management can also be automated through the API. ![image 1.png](https://assets.northflank.com/image_1_d40cc4b186.png) On Northflank Cloud, Harnesses run in an isolated microVM. Each Harness has its own kernel, filesystem, compute, and network, providing isolation between concurrently running tasks. Billing runs per second of active compute, so the compute cost of an ephemeral Harness follows how long it is actively running. When a task needs to continue across sessions, enable workspace persistence so you can pause the Harness and return to its files later. For teams with compliance or data residency requirements, BYOC lets you run Harnesses inside your own AWS, GCP, Azure, Oracle, or CoreWeave account. > Create your first Harness on [Northflank](https://app.northflank.com/signup), or follow the [quick start guide](https://northflank.com/docs/v1/application/cloud-harness/quickstart) for the full setup. > ### When should you use an ephemeral or persistent Harness? | Situation | Workspace persistence | What to do | | --- | --- | --- | | Short, single-task agent work | Disabled | Push the work when finished; delete the Harness when no longer needed | | Task spans several sessions | Enabled | Stop and resume the Harness as needed; delete it when no longer needed | | Pull request waiting for review | Optional | Enable persistence if you want to return to the same workspace; otherwise push the work and use a new Harness for review changes | | Task abandoned or failed | Either | Delete the Harness when it is no longer needed | | Task involves sensitive code or credentials | Depends on the task | Keep access scoped and delete the Harness when it is no longer needed | | Long-running development workspace | Enabled | Keep the workspace persistent across sessions | Use workspace persistence when files and agent sign-ins need to survive stops, restarts, or redeploys. Leave it disabled for fully ephemeral tasks where each environment should start clean. Delete Harnesses when they are no longer needed. ## FAQ: how to give coding agents ephemeral development environments ### Is a Northflank Harness ephemeral or persistent? Both, depending on how you configure and use it. You can leave workspace persistence disabled for a fully ephemeral Harness, where files and agent sign-ins are lost when the Harness stops, restarts, or redeploys. Enable workspace persistence when a task needs to retain its files across stops or restarts. You can still delete the Harness once the task is complete and its work has been pushed to Git. ### What is the difference between an ephemeral development environment and a sandbox? A sandbox is an isolation boundary for running code safely, separate from the host system. An ephemeral development environment is a full workspace with a lifecycle tied to one task. It includes the repository, toolchain, agent, secrets, and isolation needed to complete that task. An ephemeral development environment can run inside a sandbox. On Northflank, each Harness uses a microVM for isolation and provides the development workspace around it. ### Can I create ephemeral development environments automatically for each task? Yes. The dashboard covers manual workflows, but teams that want a Harness created for every new ticket or issue can use the [Northflank API](https://northflank.com/docs/v1/api/introduction) to manage Harnesses programmatically, including creating, pausing, resuming, and deleting them from a script or CI job. ### Do ephemeral development environments slow down agent startup? Creating the environment and cloning the repository add some startup time. However, the agent CLI is pre-installed in every Harness, so you don't need to install it at the start of each task. Your project's dependencies may still need to be installed when the agent runs the build or tests. ## Related articles - [How to give AI coding agents secure access to private repositories, databases, and services](https://northflank.com/blog/how-to-give-ai-coding-agents-secure-access-to-private-repositories-databases-and-services) - [How to run multiple coding agents in parallel](https://northflank.com/blog/how-to-run-multiple-coding-agents-in-parallel) - [Ephemeral execution environments for AI agents](https://northflank.com/blog/ephemeral-execution-environments-ai-agents)

How to run multiple coding agents in parallel

2026-10-01T14:30:00.000Z

## TL;DR: how to run multiple coding agents in parallel - You can run multiple coding agents in parallel by giving each agent its own working copy of the repository and branch, using Git worktrees on one machine or separate environments per agent. Common patterns include running the same agent on different tasks, different agents on different tasks, or different agents on the same task to compare results. - Running several agents on one machine can lead to file conflicts, shared CPU and memory usage, port collisions, and managing credentials for multiple model providers on one laptop. Your agents can also be interrupted when your laptop sleeps or shuts down. - [Northflank Cloud Harnesses](https://northflank.com/docs/v1/application/cloud-harness/quickstart) provide isolated cloud environments for running coding agents in parallel, supporting Claude Code, Codex, Cursor, OpenCode, Pi, and Bring Your Own Agent. Teams can collaborate across Harnesses and see what other members are working on in real time. Harnesses run on [Northflank's managed cloud](https://northflank.com/features/managed-cloud) or in your own cloud through [self-serve BYOC](https://northflank.com/features/bring-your-own-cloud), with microVM isolation, persistent storage, configurable compute and networking, and SSH access. > Run multiple coding agents in parallel with [Northflank Cloud Harnesses](https://app.northflank.com/signup), or [book a demo](https://cal.com/northflank/demo) to discuss your setup. > Development teams rarely use a single coding agent anymore. One developer might use Claude Code for refactors, Codex for test generation, and OpenCode with a different model for a specific codebase. Running these agents in parallel, across separate tasks or against each other on the same task, lets you make progress on multiple pieces of work at the same time. Running several agents on one machine creates conflicts. Agents can edit the same files, start development servers on the same ports, and require credentials from different providers on the same laptop. Cloud environments give each agent room to work independently while making it easier for teams to collaborate and see what others are working on. This guide covers the different ways to run coding agents in parallel, how to set them up locally, and how to run them on Northflank Cloud Harnesses. ## Why run multiple coding agents in parallel? Running multiple coding agents gives you more ways to approach development work. Instead of relying on one agent to handle every task, you can split work across agents, use different agents for different parts of a project, or compare their solutions to the same problem. For example, you could have Claude Code work on a refactor while Codex writes tests for another part of the codebase. You could also give both agents the same task and compare their implementations to see how they approach the problem. This is useful when evaluating different models and coding agents against your actual codebase. It also gives you more flexibility when working with different model providers. If one provider reaches its usage limit or becomes unavailable, you can continue working with an agent connected to another provider. ## What are the ways to run coding agents in parallel? There are three common patterns for running coding agents in parallel. | Pattern | What it looks like | Best for | Main risk | | --- | --- | --- | --- | | Same agent, different tasks | Multiple sessions of the same coding agent, each working on a separate branch | Splitting a backlog across one familiar agent | File conflicts and shared resource usage | | Different agents, different tasks | Claude Code on a refactor, Codex on tests, OpenCode on documentation | Matching different tasks to different agents | Inconsistent conventions across agents | | Different agents, same task | Claude Code and Codex given the same prompt and starting commit | Comparing agents on your own codebase | Paying for multiple implementations of the same task | > For a detailed walkthrough of running multiple sessions of the same agent, see [How to run multiple Claude Code sessions in parallel](https://northflank.com/blog/how-to-run-multiple-claude-code-sessions-in-parallel). > ## How to run multiple coding agents in parallel locally You can run different coding agents on your local machine using Git worktrees and separate terminal sessions. Each worktree gives an agent its own working directory and branch, so multiple agents can work on the same repository without editing the same files. For example, you can create one worktree for Claude Code and another for Codex: ```bash # From your main repository git worktree add ../myapp-claude -b claude-refactor git worktree add ../myapp-codex -b codex-tests # Start Claude Code in its worktree cd ../myapp-claude claude ``` Open another terminal tab and start Codex in its worktree: ```bash cd ../myapp-codex codex ``` You can repeat this for other coding agents, such as OpenCode or Pi, as long as their CLIs are installed and authenticated on your machine. Each worktree has its own working directory, so you'll need to install project dependencies separately. For example, `node_modules` and Python virtual environments aren't shared between worktrees. Each agent also needs its own provider authentication and configuration. #### Managing multiple agent sessions Terminal tabs are a simple way to keep each agent in a separate session. You can also use `tmux` to create and manage named sessions: ```bash # Start a session for each agent tmux new -s claude -c ../myapp-claude tmux new -s codex -c ../myapp-codex # List active sessions tmux ls ``` You can detach from a tmux session and return to it later, even after closing your terminal window. However, tmux doesn't keep processes running if your laptop sleeps, restarts, or loses power. Git worktrees keep the agents' working files separate, but they don't isolate the underlying machine. All agents still share your CPU, memory, network, and other local resources. ## What breaks when you run multiple coding agents on one machine? Git worktrees keep agents out of each other's working directories, but everything else on the machine is still shared. Running different agents also introduces problems that you might not encounter when running several sessions of the same agent. | Problem | What happens | Local workaround | On Northflank Cloud Harnesses | | --- | --- | --- | --- | | File conflicts | Two agents edit the same files or overwrite each other's changes. | Git worktrees or separate repository clones. | Use worktrees inside one Harness or give each agent its own Harness and filesystem. | | CPU and memory | Builds, tests, and agent processes compete for the same machine resources. | Run fewer agents at once or use a more powerful machine. | Each Harness has its own configurable compute resources. | | Port collisions | Two agents start development servers on the same port. | Assign different ports to each agent. | Each Harness has its own network environment and endpoints. | | Credential management | Anthropic, OpenAI, and other provider credentials accumulate on one laptop. | Manage API keys and authentication separately for each agent. | Configure the credentials each agent needs in its Harness. | | Tooling conflicts | Agents need different CLI versions, configuration directories, or runtimes. | Use version managers and configure separate environments. | Each Harness has its own runtime and environment configuration. | | Laptop availability | Sleep, restarts, or a closed lid can interrupt every running agent. | Keep the machine awake and plugged in. | Harnesses run in the cloud independently of your laptop. | | Isolation | A destructive command from one agent can affect other projects and processes on the machine. | Configure containers or virtual machines manually. | Each Harness runs in its own microVM. | Two agents handling light tasks can usually run on a capable machine. The limitations become more noticeable with long-running tasks, heavy builds, multiple providers' credentials, or agents that need to keep running after you leave your desk. [Northflank Cloud Harnesses](https://northflank.com/docs/v1/application/cloud-harness/quickstart) also make parallel work easier to coordinate across a team. Multiple team members can collaborate in Harnesses and see what others are working on in real time, without sharing a single developer's local machine. ## How do Northflank Cloud Harnesses help you run multiple coding agents in parallel? [Northflank Cloud Harnesses](https://northflank.com/docs/v1/application/cloud-harness/quickstart) are cloud workspaces built for coding agents. When you create a Harness, you choose the agent it runs: Claude Code, Codex, Cursor, OpenCode, Pi, or Bring Your Own Agent. The agent comes pre-installed, its credentials are configured for the environment, and the Harness can clone a connected Git repository and branch on start. You can access a Harness through the web terminal in the Northflank dashboard or over SSH from your local machine. For parallel agents, each Harness provides a configured workspace for an agent to work independently. A Claude Code Harness, a Codex Harness, and an OpenCode Harness can all work on the same repository at the same time, each with its own branch, compute resources, filesystem, and credentials. None of them depend on your laptop staying on. Harnesses also support team collaboration. Multiple team members can access workspaces, follow what others are working on in real time, review agent output, and continue tasks without having to share a local development environment. Harnesses on Northflank Cloud run in isolated microVMs. Harnesses are persisted between restarts, so you can pause a Harness and resume it later with the same files, branches, and installed packages. Billing runs per second of active compute, and pausing a Harness stops compute billing while preserving its workspace. For teams with compliance or data residency requirements, bring your own cloud (BYOC) lets you run Harnesses inside your own AWS, GCP, Azure, Oracle, or CoreWeave account. > Create your first Harness on [Northflank](https://app.northflank.com/signup), or follow the [quick start guide](https://northflank.com/docs/v1/application/cloud-harness/quickstart) for the full setup. > ### How to run different coding agents in parallel on Northflank Each coding agent runs in its own Harness. Create one Harness per agent, connect them to the same repository, and give each one its own branch. ![image.png](https://assets.northflank.com/image_7155c5d8ce.png) 1. Create a Harness and select Claude Code. Connect your repository and select a branch ([see quick start guide](https://northflank.com/docs/v1/application/cloud-harness/quickstart)). 2. Repeat to create additional Harnesses for Codex, Cursor, OpenCode, Pi, or Bring Your Own Agent. 3. Select compute size for each Harness based on its task. A large refactor may need more CPU and memory than a documentation update. 4. Open each Harness from the sidebar and start its agent using the relevant CLI, such as `claude`, `codex`, or `opencode`. 5. Give each agent its task. They can now work in parallel, each in its own microVM. 6. Pause each Harness when its task is complete. You can resume it later to continue working or review its output. Each Harness has its own repository clone and filesystem, so you don't need Git worktrees to keep agents' files separate. You can also configure compute resources and credentials independently for each Harness. ### How to compare coding agents on the same task Running two or more agents on the same task lets you compare how they handle your codebase, conventions, and tests. 1. Pick a base commit or branch and create one Harness per agent, all connected to the same starting point. 2. Have each agent create its own branch from the base, such as `claude-auth-fix` and `codex-auth-fix`. 3. Give every agent the same prompt and acceptance criteria. 4. Let each agent finish, then run the same test suite in each Harness. 5. Open a pull request for each branch and compare the diffs, test results, and how much rework each implementation needs. 6. Merge the implementation you want to keep and pause the other Harnesses. Keep the prompt, base commit, acceptance criteria, and test conditions consistent across Harnesses so the comparison reflects the agents rather than differences in the setup. ## How to manage and review work from parallel coding agents 1. **Use a separate branch for each task:** Give each agent its own branch so its changes can be reviewed and merged independently. 2. **Scope each prompt:** Tell each agent which directories, files, or modules it should work on. Assigning separate areas of the codebase reduces the chance of agents editing the same files and creating merge conflicts. 3. **Share instructions across agents:** Keep your project conventions, coding standards, and test commands in a shared instruction file. For example, Codex and some other agents support `AGENTS.md`, while Claude Code supports `CLAUDE.md`. You can reference shared instructions from agent-specific files so each agent follows the same standards. 4. **Review changes through pull requests:** Open a pull request for each agent's branch and review the changes independently. After merging a branch, update any remaining branches against the latest base branch before merging them. 5. **Bring in teammates:** With Northflank Cloud Harnesses, teammates can open an agent's Harness to review its output or continue its task without setting up the environment again. Team members can also see what others are working on in real time. 6. **Pause finished Harnesses:** Once an agent has pushed its changes and no longer needs to run, pause its Harness to stop compute usage while preserving its workspace. ## FAQ: how to run multiple coding agents in parallel ### Can I run Claude Code and Codex on the same repository at the same time? Yes. Give each agent its own branch, using Git worktrees if they share one machine or separate Harnesses if you are running them in the cloud. Connect each Harness to the same repository and assign a different branch to each agent. Scope their tasks to different parts of the codebase to reduce merge conflicts. ### Do different coding agents share usage limits? No. Usage limits depend on the model provider and account each agent uses, not simply on the coding agent. For example, Claude Code and OpenCode using the same Anthropic account may draw from the same usage limits. Running agents in separate Harnesses does not give you additional provider quota. ### Which coding agent should I use for which task? It depends on your codebase, language stack, and the models available to each agent. Rather than relying only on public benchmarks, you can give two or more agents the same task and starting commit, then compare their implementations and test results on your own repository. ### Do I need Git worktrees if each agent has its own Harness? No. Each Harness has its own repository clone and filesystem, so agents working in separate Harnesses cannot overwrite each other's local files. Git worktrees are useful when multiple agent sessions share one Harness or local machine. ### Can I run a coding agent that Northflank does not list? Yes. Bring Your Own Agent lets you configure a Harness for a CLI-based coding agent that is not on the default list. You install and configure the agent in the Harness, which provides the same microVM isolation, workspace persistence, and access options available to other Harnesses. ## Related articles - [How to run multiple Claude Code sessions in parallel](https://northflank.com/blog/how-to-run-multiple-claude-code-sessions-in-parallel) - [How to run a coding agent in the cloud](https://northflank.com/blog/how-to-run-coding-agents-in-the-cloud) - [What is a coding harness?](https://northflank.com/blog/what-is-a-coding-harness)

How to give AI coding agents secure access to private repositories, databases, and services

2026-09-30T20:45:00.000Z

## TL;DR: how to give AI coding agents secure access - AI coding agents need access to private repositories, databases, APIs, and other services to complete real development tasks. Secure access means giving agents only the credentials and network access they need, rather than unrestricted access to your infrastructure. - Use scoped credentials, runtime secrets injection, private networking, and isolated execution environments to control what an agent can access and limit the impact of a compromised or misbehaving agent. - **[Northflank Cloud Harnesses](https://northflank.com/docs/v1/application/cloud-harness/quickstart) provide the infrastructure for securely running coding agents in isolated cloud environments**, with support for private repositories, secrets injection, configurable networking, microVM isolation, persistent storage, and managed cloud or self-serve bring your own cloud (BYOC) deployments. Teams can collaborate across Harnesses and see what other members are working on in real time. > Give your coding agents secure access to private repositories, databases, and services with [Northflank Cloud Harnesses](https://app.northflank.com/signup) or [book a demo](https://cal.com/northflank/demo) to discuss your setup. > AI coding agents need real access to do real work. An agent fixing a bug in a private repository has to clone it, an agent writing a migration has to connect to a database, and an agent calling an internal API has to authenticate against it. The way most developers handle credentials locally does not always translate safely to agent workloads: a `.env` file in an agent's working directory is accessible to the agent and can potentially be read, modified, or committed. This article covers how to give coding agents scoped access to private repositories, databases, and services, how secrets injection works in a coding harness, and which mistakes to avoid when configuring access for agent workloads. ## Why is access management different for coding agents A developer authenticates interactively. They log in once, their session is tied to their identity, and they can intervene if something goes wrong. A coding agent authenticates at execution time and can then run unattended, executing commands and using credentials without a human watching every action. Agents also execute code generated by a model, so their use of credentials is not always predictable. An agent with read-write access to a database could execute a `DELETE` statement when the task only required a `SELECT`, while an agent with broad repository access could modify repositories unrelated to the task. This is why coding agents need scoped credentials and controlled access to the resources they actually need. ## How to give coding agents access to private repositories Personal access tokens are the default way developers authenticate against hosted Git services. They are convenient for interactive use but poorly suited to agent workloads because they can carry broad permissions and are tied to a user account. An agent running with a personal access token can inherit the same repository access as the developer who created it. Deploy keys and short-lived tokens can scope access to a specific repository. A deploy key is a key pair where the public key is registered on the repository, granting access only to that repository. Short-lived tokens generated by apps or CI integrations expire after a fixed window, limiting how long an exposed credential remains usable. Both approaches can limit the impact if a credential is exposed or misused. **Northflank Cloud Harnesses connect to private repositories through linked Git integrations.** When you create a Harness, you can select a repository and branch, and Northflank clones the repository into the Harness workspace. GitHub, GitLab, Bitbucket, Azure DevOps, Cursor Origin, and self-hosted Git providers are supported. Org-wide tokens are a meaningful risk in agent workloads. A token that can read and write all repositories in an organisation gives an agent access to repositories unrelated to its task and increases the potential impact if the credential is misused. Restricting repository access to what the agent actually needs reduces that blast radius. ## How to give coding agents access to databases and services Database access for coding agents should follow the same principle as repository access: give the agent only the permissions required for the task. An agent reviewing query performance does not need write access, while an agent running a migration may need write access without needing administrator access to the entire database. Use dedicated credentials for agent workloads rather than reusing production application credentials. Inject connection strings, API keys, and service credentials as runtime environment variables or secret files instead of hardcoding them in the repository. Northflank Cloud Harnesses support both, so you can provide agents with the credentials they need without committing them to the codebase. The same approach applies to external APIs and internal services. Use credentials with the minimum required permissions and restrict network access to the services the agent actually needs. | Resource | What to scope | What to avoid | | --- | --- | --- | | Database | User permissions and database access | Administrator or production credentials | | External API | API key permissions | Broad keys shared across agents | | Internal service | Service account and network access | Broad access to unrelated services | ## How secrets injection works in a coding harness A coding harness manages the execution environment for an agent. Secrets injection means the harness stores credentials securely and makes them available to the agent at runtime, rather than requiring credentials to be hardcoded or stored in the working directory. **Northflank Cloud Harnesses support runtime environment variables and secret files**, allowing you to provide database credentials, API keys, and other configuration to an agent without committing them to the repository or hardcoding them into the workspace. This is safer than common local patterns such as `.env` files, shell commands containing credentials, or hardcoded values in configuration files. These can be read by the agent, committed to version control, or exposed in logs and shell history. Secrets injection does not prevent an agent from accessing a credential it has been given, but it reduces the risk of credentials being accidentally persisted in the workspace. ## Common mistakes when giving coding agents access to private resources ### 1. Using credentials with broader access than necessary Personal access tokens and shared service credentials can give an agent access to repositories, databases, or services it has no reason to reach. Use credentials scoped to the specific resource and permissions the task requires. ### 2. Hardcoding credentials in files the agent can read and commit Credentials stored in `.env` files, configuration files, or source code can be read by the agent, committed to version control, or exposed in logs. Use runtime environment variables or secret injection instead. ### 3. Giving agents write access when read access is enough An agent reviewing data does not need permission to modify it. Start with read-only access where possible and grant write access only when the task requires it. ### 4. Sharing credentials across agents and environments Using the same credentials across multiple agents or environments makes access harder to control and rotate. Use separate credentials for different agents, environments, and levels of access, particularly when production resources are involved. ## How Northflank secures access for AI coding agents [Northflank Cloud Harnesses](https://northflank.com/docs/v1/application/cloud-harness/quickstart) provide the infrastructure for giving coding agents controlled access to private resources. You can connect private repositories through Git integrations, inject secrets at runtime, configure networking, and run each Harness in an isolated environment. ![image.png](https://assets.northflank.com/image_7155c5d8ce.png) Secrets can be stored in **Northflank secrets groups** and attached to individual Harnesses. They are injected into the agent's environment at runtime, while secret files are also supported when credentials need to be provided as files. Git access works through Northflank's Git integrations. When a repository is configured on a Harness, Northflank clones it into the workspace so the agent can work with the code without manually adding Git credentials to the workspace. Each Harness runs in an **isolated microVM environment**. For teams that need access to private databases and internal services, Harnesses can also run through bring your own cloud (**BYOC)** in AWS, GCP, Azure, Oracle Cloud, or CoreWeave, allowing agents to connect to resources inside their own cloud infrastructure. Teams can collaborate across Harnesses and see what other members are working on in real time. > Give your coding agents controlled access to private repositories, databases, and services with [Northflank Cloud Harnesses](https://app.northflank.com/signup) self-serve or [book a demo](https://cal.com/northflank/demo) to discuss your setup. > ## FAQ: ### What is the difference between secrets injection and environment variables? Environment variables are the delivery mechanism. Secrets injection is how a platform securely makes stored credentials available to the agent at runtime without hardcoding them in the workspace. ### Should coding agents use the same credentials as CI pipelines? No. Coding agents execute model-generated code and have different access requirements from CI pipelines. Using separate credentials lets you revoke or rotate agent access without affecting your CI environment. ### How do I rotate credentials for a running agent? Update the secret in your platform and restart Harness so the new value is injected when it starts. Short-lived credentials can also reduce the need for manual rotation. ### What happens if a coding agent commits a credential to Git? Treat the credential as compromised. Revoke or rotate it immediately, then remove it from the repository's Git history and check whether your Git provider's secret scanning detected it. ### Does BYOC deployment keep agent traffic inside my own cloud account? Yes. With BYOC, the Harness runs in your own AWS, GCP, Azure, Oracle Cloud, or CoreWeave infrastructure, allowing agents to connect to private resources through your cloud network. ## Related articles - [What is a coding harness?](https://northflank.com/blog/what-is-a-coding-harness) - [What are cloud coding agents?](https://northflank.com/blog/what-are-cloud-coding-agents) - [How to run a coding agent in the cloud](https://northflank.com/blog/how-to-run-coding-agents-in-the-cloud)

How to run multiple Claude Code sessions in parallel

2026-09-30T15:00:00.000Z

## TL;DR: how to run multiple Claude Code sessions in parallel - You can run multiple Claude Code sessions in parallel to work on different tasks simultaneously. Each session should have its own working directory and Git state to avoid conflicts. - Running several sessions on a single machine means they share the CPU, memory, ports, and other resources. Git worktrees help isolate the code, but not the underlying environment. - [Northflank Cloud Harnesses](https://northflank.com/docs/v1/application/cloud-harness/quickstart) let you run multiple Claude Code sessions in isolated cloud environments, either by running several sessions in one Harness or giving each session its own Harness with dedicated resources. With support for Codex, Cursor, OpenCode, Pi, or a bring your own agent. Harnesses run on [Northflank's managed cloud](https://northflank.com/features/managed-cloud) or in your own AWS, GCP, Azure, Oracle, or CoreWeave account through [self-serve BYOC](https://northflank.com/features/bring-your-own-cloud), with microVM isolation, persistent storage, configurable compute and networking, and SSH access. - Use one Harness for small, related tasks that can share an environment, or separate Harnesses when sessions need independent resources and stronger isolation. Teams can collaborate across Harnesses and see what other members are working on in real time. > Run multiple Claude Code sessions in parallel with [Northflank Cloud Harnesses](https://app.northflank.com/signup). or [book a demo](https://cal.com/northflank/demo) to discuss your setup. > Claude Code works through one task per session. When you have a bug fix, a refactor, and a new test suite to write, running them one after another means waiting on each before starting the next. Running several sessions in parallel lets each task progress at the same time, with each session focused on its own task. Parallel sessions on one machine introduce their own problems: two sessions editing the same files, development servers competing for the same port, and a laptop that has to stay awake until every session finishes. This guide covers how to run parallel Claude Code sessions locally, where that approach breaks down, and how to run them on Northflank Cloud Harnesses instead. ## Why run multiple Claude Code sessions in parallel? Most development work splits into independent tasks. A bug fix in the authentication module has nothing to do with a refactor of the API client. Running both in separate sessions at the same time lets you make progress on both instead of running them in sequence. Long tasks also stop blocking short ones. A session working through a large migration can run for an hour while a second session handles a small fix and a third writes tests. You can review each result as it completes. Each session keeps a focused context. Mixing unrelated tasks in one session fills the context window with files and history that have nothing to do with the current task. Separate sessions keep each context focused and relevant. Parallel sessions also let you compare approaches. You can give two sessions the same problem with different instructions and compare the results. ## How to run parallel Claude Code sessions locally There are three common ways to run parallel Claude Code work on your own machine. ### 1. Git worktrees A Git worktree is a second working directory linked to the same repository, checked out on its own branch. Each Claude Code session runs in its own worktree, so sessions do not edit the same files on disk. ```bash # From your main repository git worktree add ../myapp-auth-fix -b auth-fix git worktree add ../myapp-api-refactor -b api-refactor # Start a session in each worktree cd ../myapp-auth-fix && claude cd ../myapp-api-refactor && claude ``` Each worktree needs its own dependencies installed, since `node_modules` or virtual environments are not shared between working directories. When a task is complete, you can remove its worktree: ```bash git worktree remove ../myapp-auth-fix ``` ### 2. Terminal tabs or tmux Separate terminal tabs are the simplest way to keep several sessions visible. tmux adds named sessions that continue running when you close the terminal window: ```bash tmux new -s auth-fix -c ../myapp-auth-fix tmux new -s api-refactor -c ../myapp-api-refactor tmux ls ``` tmux keeps sessions alive when you close the terminal, but not when the laptop sleeps, restarts, or loses power. ### 3. Subagents within one session Claude Code can also delegate work to subagents, which run in parallel inside a single session with their own context. This is useful for splitting one larger task into smaller pieces, such as researching several modules at once. Subagents share the session's working environment and report back to the main session, so they are not a replacement for separate Claude Code sessions when you want independent tasks running in separate environments. ## What breaks when you run parallel sessions on one machine? Worktrees solve file conflicts, but most other resources on the machine are still shared between sessions. | Problem | What happens | Local workaround | On Northflank Cloud Harnesses | | --- | --- | --- | --- | | File conflicts | Two sessions can edit the same file and create conflicting changes | Git worktrees | Worktrees inside one Harness, or separate workspaces per Harness | | CPU and memory | Builds and test runs across sessions compete for the same resources | Run fewer sessions at once | Each Harness has its own configured compute | | Port collisions | Two sessions start development servers on the same port | Assign ports manually per session | Each Harness has its own network environment | | Shared credentials | Sessions can potentially access credentials available on the same machine | Keep credentials scoped manually | Each Harness only receives the secrets configured for it | | Laptop must stay on | Sleep, restart, or a closed lid can interrupt sessions | Keep the machine awake and plugged in | Harnesses run in the cloud independently of your laptop | | Limited isolation | A destructive command can affect other projects or processes on the machine | Use containers or VMs | Each Harness runs in an isolated microVM | Two or three light sessions on a capable machine can work well. The limits become more noticeable with longer tasks, heavier builds, or sessions that need to keep running after you leave your desk. ## How do Northflank Cloud Harnesses help you run multiple Claude Code sessions in parallel? [Northflank Cloud Harnesses](https://northflank.com/docs/v1/application/cloud-harness/quickstart) are cloud workspaces built for coding agents. Each Harness comes with Claude Code pre-installed, a web terminal in the Northflank dashboard, SSH access from your local terminal, and an optional connected Git repository and branch. You can run several Claude Code sessions in parallel by opening multiple terminal tabs in one Harness or creating a separate Harness for each session. When you use multiple Harnesses, each session runs in its own isolated microVM with its own compute, filesystem, network, and configuration. This keeps independent tasks from competing for resources or interfering with each other. If you use several sessions in one Harness, they share the same resources, so you can use Git worktrees to keep their files and branches separate. Harness workspaces persist between restarts, so you can pause a Harness and return to the same workspace files later. You can also run Harnesses in your own AWS, GCP, Azure, Oracle, or CoreWeave account through [self-serve BYOC](https://northflank.com/features/bring-your-own-cloud) when your workloads need to run inside your own cloud infrastructure. Teams can collaborate across Harnesses and see what other members are working on in real time. ### How to run multiple Claude Code sessions in one Northflank Harness 1. Create a new Harness and select **Claude** ([see quick start guide](https://northflank.com/docs/v1/application/cloud-harness/quickstart)). 2. Connect your repository and branch if needed. 3. Open the Harness terminal and create a Git worktree for each task. 4. Open a new terminal tab for each session. ![image 1.png](https://assets.northflank.com/image_1_5c09263173.png) Start Claude Code in each worktree. For example: ```bash # Session 1 git worktree add ../auth-fix -b auth-fix cd ../auth-fix claude ``` ```bash # Session 2 git worktree add ../api-refactor -b api-refactor cd ../api-refactor claude ``` All sessions share the Harness's CPU, memory, filesystem, and network, so this setup works best when the tasks are relatively small and related. ### How to run each Claude Code session in its own Harness Create a new Harness for each task ([see quick start guide](https://northflank.com/docs/v1/application/cloud-harness/quickstart)), connect the repository and branch, select the resources that the task needs, and start Claude Code from the Harness terminal. Each Harness has its own workspace and resources, so you don't need Git worktrees to separate the sessions. Development servers can also use the same ports because they run in separate network environments. This setup is useful when sessions are long-running, resource-intensive, or unrelated and should not affect each other. ### One Harness or multiple Harnesses: which should you use? | | One Harness, several sessions | One Harness per session | | --- | --- | --- | | Isolation | Sessions share one environment | Each session has its own environment | | Files | Use Git worktrees | Separate workspace per Harness | | CPU and memory | Shared | Configured per Harness | | Ports | Shared | Separate | | Pause and resume | All sessions together | Each session independently | | Setup | Open another terminal tab | Create another Harness | | Best for | Small, related tasks | Long, heavy, or unrelated tasks | Use one Harness with several sessions when you want to work quickly on related tasks in the same environment. Use one Harness per session when you need stronger isolation or want each task to have its own resources. ## How to manage and review work from parallel sessions 1. **Use one branch per session.** Every session commits to its own branch, so its work can be reviewed and merged independently. 2. **Scope each prompt.** Tell each session which directories or modules it should work on. Sessions working on separate parts of the codebase are less likely to produce merge conflicts. 3. **Share conventions through** `CLAUDE.md`**.** Claude Code reads `CLAUDE.md` files in the repository, so every session can follow the same coding standards, test commands, and project rules. 4. **Review through pull requests.** Open a pull request for each branch, review the changes, and merge them as they are ready. Rebase remaining branches when necessary. 5. **Bring in teammates.** On Northflank, teammates can access the same Harness to review a session's work or continue the task without setting up the environment again. 6. **Pause finished work.** Pause a Harness when its task is complete so you can return to it later without keeping the environment running. ## FAQ: how to run multiple Claude Code sessions in parallel ### How many Claude Code sessions can I run at once? Locally, the practical limit depends on your machine's CPU and memory as well as your Claude usage limits. With Northflank, you can run multiple sessions in one Harness or create separate Harnesses with their own configured compute. ### Do I need Git worktrees if each session runs in its own Harness? No. Each Harness has its own workspace and file system, so sessions do not share the same working directory. Git worktrees are useful when several sessions share one Harness or one machine. ### Can parallel Claude Code sessions work on the same repository? Yes. Give each session its own branch, either through a Git worktree or a separate Harness connected to the same repository. Keeping each session's task scoped also reduces merge conflicts. ### Can I run Claude Code and Codex in parallel? Yes. You can run Claude Code and Codex in separate Harnesses, with each connected to the same repository on different branches. Northflank Harnesses also support other coding agents, including OpenCode and Pi. ### Can I run multiple Claude Code sessions in the cloud? Yes. Northflank Cloud Harnesses let you run multiple Claude Code sessions in parallel, either as separate sessions in one Harness or in separate Harnesses with independent environments. ## Related articles - [How to run Claude Code in the cloud](https://northflank.com/blog/run-claude-code-in-the-cloud) - [How to run a coding agent in the cloud](https://northflank.com/blog/how-to-run-coding-agents-in-the-cloud) - [What is a coding harness?](https://northflank.com/blog/what-is-a-coding-harness)

What is a coding harness?

2026-09-29T15:30:00.000Z

## TL;DR: what is a coding harness? - A coding harness is the infrastructure layer that gives a coding agent the environment it needs to work, including a shell, file system, repository access, credentials, compute, and persistent storage. - Coding harnesses separate the coding agent from the environment it operates in, providing isolation, persistence, access controls, and the resources needed to run coding tasks locally or in the cloud. - Northflank Cloud Harnesses provide the infrastructure to run coding agents in isolated cloud environments, with support for Claude Code, Codex, Cursor, OpenCode, Pi, or a bring your own agent. Harnesses run on [Northflank's managed cloud](https://northflank.com/features/managed-cloud) or in your own AWS, GCP, Azure, Oracle, or CoreWeave account through [self-serve BYOC](https://northflank.com/features/bring-your-own-cloud), with microVM isolation, persistent storage, configurable compute and networking, and SSH access. Teams can collaborate across Harnesses and see what other members are working on in real time. > Run a coding agent in an isolated cloud harness with [Northflank Cloud Harnesses](https://app.northflank.com/signup), or [book a demo](https://cal.com/northflank/demo) to discuss your setup. > A coding harness is the infrastructure layer that connects a coding agent to everything it needs to operate: a shell, a repository, credentials, persistent storage, and an isolated execution environment. Without a coding harness, a coding agent has no place to run code, no file system to read and write, and no way to persist work between sessions. This article explains what a coding harness is, how it works, what it consists of, and how it differs from adjacent concepts like agent frameworks and sandboxes. ## What is a coding harness? A coding harness is the infrastructure layer that wraps a coding agent and gives it a place to operate. It provides the execution environment the agent works inside, including the operating system, shell, file system, repository, credentials, and network access it needs to complete coding tasks. The agent decides what actions to take and generates the code or instructions, while the harness provides the environment and tools needed to execute them. The term comes from testing infrastructure, where a test harness provides the scaffolding needed to run tests in a controlled environment. A coding harness applies the same idea to coding agents: it creates a controlled, repeatable environment for an agent to work in, separate from the developer's own machine. Claude Code, Codex, and OpenCode are coding agents, not coding harnesses. The harness provides the environment they operate in, while the agent handles the coding task. ## How does a coding harness work? A coding harness provides the execution layer around a coding agent. When a developer gives a coding agent a task, the workflow looks like this: 1. **Connect to the harness:** The developer connects to the harness environment, typically through SSH for a cloud harness or a local process for a local harness. 2. **Start the coding agent:** The agent starts inside the harness with access to the file system, repository, and any configured credentials. 3. **Request an action:** The agent sends the task and relevant context to the model. The model returns an action, such as running a command, editing a file, or reading a log. 4. **Execute the action:** The harness provides the tools and environment needed to execute the action. The shell runs the command, the file system records the edit, and the test runner returns its output. 5. **Return the result:** The result is passed back to the agent as an observation. The agent sends the updated context back to the model and continues the loop. 6. **Preserve the workspace:** When the task is complete, or the developer pauses the environment, the harness can preserve the workspace state so files, installed packages, and Git history remain available. The harness connects the coding agent to the underlying infrastructure. It controls what the agent can access, provides credentials and tools at runtime, and keeps the workspace available independently of whether the developer is connected. ## What are the components of a coding harness? A coding harness has six core components. 1. **Isolated execution environment:** The workspace where the agent operates. A production coding harness can use a microVM or another isolated environment to prevent the agent from affecting other workloads or the host system. The environment includes the operating system, development tools, and any packages the agent needs to install. 2. **Shell and file system access:** The agent needs a shell to run commands and a file system to read and write files. The harness provides both within the workspace, giving the agent access to the files and directories it needs without exposing the developer's entire machine. 3. **Repository connection:** Most coding agents work against a Git repository. The harness can clone the repository into the workspace and provide the Git credentials needed to pull, commit, and push changes. 4. **Secrets and credentials injection:** Coding agents often need credentials to call model APIs, access Git repositories, or interact with other services. A harness provides a way to securely make these credentials available to the agent at runtime rather than putting them directly in the code. 5. **Persistent storage:** The workspace can persist between sessions. When a harness is paused and resumed, files, installed packages, and Git history can remain available. This means long-running tasks do not require the developer to keep an active session open. 6. **SSH access:** For cloud coding harnesses, SSH gives developers a terminal inside the remote workspace. The coding agent can run there independently of the developer's local machine, allowing the developer to connect, start a task, disconnect, and reconnect later. [Northflank Cloud Harnesses](https://northflank.com/docs/v1/application/cloud-harness/quickstart) bring these components together in a managed cloud workspace, providing configurable compute, storage, networking, repository access, remote access, and persistent workspace state for coding agents ## Coding harness vs agent framework vs sandbox These three terms are often used together, but they refer to different layers of the same stack. | | Coding harness | Agent framework | Sandbox | | --- | --- | --- | --- | | **What it is** | The environment and infrastructure a coding agent operates in | The building blocks for developing and orchestrating agents | An isolated environment for running code | | **Primary role** | Provides the shell, file system, repository, credentials, and workspace the agent uses | Manages model calls, context, tools, and agent workflows | Isolates code execution from the host system | | **Where it sits** | Between the agent and the underlying infrastructure | Between the application or task and the agent | Between the code and the underlying system | | **Handles persistence** | Yes | Sometimes | Can | | **Handles credentials** | Yes | Sometimes | Can | | **Handles repository access** | Yes | Can, depending on the implementation | Can | | **Primary concern** | Infrastructure, workspace, and isolation | Agent orchestration and workflows | Security and containment | A coding harness can use a sandbox as its execution layer. The sandbox provides the isolation boundary, while the harness provides everything around it, such as the repository, credentials, persistent storage, and remote access. An agent framework sits at a different layer. It provides the components used to build and orchestrate an agent, including model calls, tool routing, context management, and task logic. The framework does not necessarily need to know where the agent's code is running. The boundaries can overlap. Some coding agents, such as Claude Code and Codex, include their own agent loop and tooling, while a cloud coding harness provides the infrastructure those agents run inside. ## What happens without a coding harness? Without a coding harness, a coding agent typically runs directly on the developer's local machine, with access to the local shell and file system. This gives the agent little separation from the rest of the machine, so an unexpected tool call, prompt injection, or incorrect file path could expose files, credentials, or processes outside the project it is working on. There is also no built-in shared workspace or managed persistence model. When the local session ends, the agent is tied to that local environment, and another developer cannot simply connect to the same workspace and continue the task. A coding harness adds these missing boundaries by providing an isolated environment, controlled access to credentials and resources, persistent workspace state, and a way for developers to reconnect to and share ongoing work. ## Where does a coding harness run? A coding harness can run locally or in the cloud, depending on the workload. - **Local:** A local coding harness runs on the developer's own machine. The agent has access to the local shell and file system, with additional isolation possible through containers or other runtime controls. Local harnesses work well for development and testing where the developer is actively supervising the agent. - **Cloud.** A cloud coding harness runs in a remote environment, typically using an isolated VM or microVM on managed infrastructure or inside the developer's own cloud account. For example, Northflank Cloud Harnesses provide isolated cloud workspaces with configurable compute, storage, networking, and persistent state. Harnesses can run on Northflank's managed cloud or inside your own AWS, GCP, Azure, Oracle, or CoreWeave infrastructure through BYOC. For teams with compliance or data residency requirements, a BYOC deployment can run the harness inside their own cloud account, keeping the workspace and its resources within their infrastructure. ## How Northflank supports coding harnesses **Northflank Cloud Harnesses provide the infrastructure for running coding agents in isolated cloud environments**, with support for Claude Code, Codex, Cursor, OpenCode, Pi, or bring your own agent. Each Harness provides the compute, storage, networking, development tools, credentials, and persistent workspace state a coding agent needs to work. ![image.png](https://assets.northflank.com/image_7155c5d8ce.png) Harnesses run on **Northflank's managed cloud** or in your own AWS, GCP, Azure, Oracle, or CoreWeave account through **self-serve BYOC**. Each Harness runs in an isolated microVM environment, giving teams control over where their coding environments run while keeping the workspace separate from other workloads and the host infrastructure. Teams can collaborate across Harnesses and see what other members are working on in real time. You can create a Harness from the Northflank dashboard, connect to it remotely through SSH, and run a coding agent in the same way you would locally. The workspace persists between sessions, so you can disconnect and return to the same environment without losing your files, dependencies, or Git history. > Run a coding agent in an isolated cloud harness with [Northflank Cloud Harnesses](https://app.northflank.com/signup), or [book a demo](https://cal.com/northflank/demo) to discuss your team's setup. > ## FAQ: what is a coding harness? ### Is a coding harness the same as a development environment? No. A development environment is a general-purpose setup for writing and testing code, while a coding harness provides an environment specifically for coding agents, with isolation, access controls, credentials, and persistent workspace state. ### What is the difference between a coding harness and a sandbox? A sandbox focuses on isolating code execution from the host system. A coding harness is broader, providing the workspace, repository access, credentials, persistence, and other infrastructure the coding agent needs to operate. ### Can a coding harness run multiple agents at the same time? Yes. You can run multiple coding agents by creating separate harnesses for each agent or task. This keeps their workspaces and execution environments isolated from one another. ### Do I need a coding harness to run a coding agent? No. A coding agent can run directly on a local machine, but a coding harness provides additional isolation, persistence, access controls, and a dedicated workspace for the agent. ### Which coding agents work with a coding harness? Any coding agent that can run in the harness environment can be used. Northflank Cloud Harnesses support Claude Code, Codex, Cursor, OpenCode, Pi, and bring your own agent. ## Related articles - [How to run a coding agent in the cloud](https://northflank.com/blog/how-to-run-coding-agents-in-the-cloud) - [What is an AI agent harness?](https://northflank.com/blog/what-is-an-agent-harness) - [What are cloud coding agents?](https://northflank.com/blog/what-are-cloud-coding-agents)

How to run coding agents in the cloud

2026-09-28T16:15:00.000Z

## TL;DR: how to run an AI coding agent in the cloud - Running a coding agent in the cloud gives it an isolated environment with its own compute, storage, networking, and development tools. - Cloud environments make it easier to run coding agents for longer tasks, preserve work between sessions, and control the resources, credentials, and infrastructure they can access. - [Northflank Cloud Harnesses](https://northflank.com/docs/v1/application/cloud-harness/quickstart) provide managed cloud workspaces for coding agents, including Claude Code, Codex, Cursor, OpenCode, Pi, or Bring Your Own Agent, with persistent storage, SSH access, and Bring Your Own Cloud (BYOC) support. > **Run a coding agent in the cloud with Northflank.** Create a Cloud Harness and start working with your preferred coding agent. [Get started](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > Coding agents, also called AI coding agents, can inspect repositories, modify files, install dependencies, run commands, and test changes with little intervention. But when you run an agent locally, it shares your machine's resources, files, credentials, and development environment. For longer or more complex tasks, this can make isolation, persistence, and resource management harder to control. Running a coding agent in the cloud gives it a dedicated environment with its own compute, storage, networking, and configuration. You can connect to the workspace remotely, keep it running while you disconnect, and control which resources the agent can access. This guide explains why you might run a coding agent in the cloud, what the environment needs, and how to set one up with Northflank Cloud Harnesses. ## Why run a coding agent in the cloud rather than locally? ### Isolate coding agents from your local machine A coding agent needs to execute commands and modify files to complete tasks. Running it in a dedicated cloud environment keeps those operations separate from your personal development environment. You can give the agent access to the repository and tools it needs without giving it access to unrelated files, applications, or credentials on your laptop. ### Run long-running tasks without keeping your laptop open Some coding tasks involve large dependency installations, long test suites, builds, or multiple iterations. A cloud workspace can continue running while you disconnect from it. You can pause the environment when you are finished and resume it later, with persistent workspace storage keeping the files you need between sessions. ### Give your team access to the same workspace A cloud workspace can also make coding agents easier to use across a team. Instead of an agent running on one developer's laptop, multiple authorised team members can access the same environment and collaborate on the work. Northflank Cloud Harnesses support multiple team members working in the same workspace. Teams can also create multiple Cloud Harnesses to run coding agents in parallel, with separate workspaces for different repositories or tasks. These Harnesses can run on Northflank's managed cloud or inside your own VPC through BYOC. ### Run coding agents in your own cloud For teams with specific infrastructure, networking, or compliance requirements, running the agent in your own cloud account can provide more control over where the workspace and its underlying resources run. Northflank Cloud Harnesses can run on Northflank's managed cloud or in your own cloud infrastructure through BYOC. ## What does a coding agent need to run in the cloud? A coding agent needs more than a model and a terminal. It needs a development environment where it can access code, execute tools, store its work, and reach the resources required by the task. - **Isolated workspace:** The agent needs an isolated environment where it can inspect files, modify code, install dependencies, and run commands. This can be a virtual machine, container, sandbox, or managed cloud workspace. - **Repository access:** Most coding tasks start with an existing codebase. The environment should be able to access the relevant repository and branch while limiting access to repositories the agent does not need. - **Agent authentication:** Each coding agent requires its own credentials: an API key for Claude Code, an API key for Codex, or equivalent for other agents. These should be stored as secrets in the platform and injected at runtime, not hardcoded in the environment. - **Developer tool access:** The agent needs to invoke the same tools a developer would use: package managers, build tools, test runners, linters. The environment should come with these pre-installed or allow installing them without manual setup. - **Resource configuration:** Long-running tasks need enough CPU and memory to complete, while short-lived tasks should not require oversized environments. The platform should let you configure resources based on the workload and adjust them as requirements change. - **SSH connection:** For CLI-based coding agents such as Claude Code, Codex, and OpenCode, SSH provides a familiar way to access the cloud environment from your local terminal. - **Pause and resume:** An agent working on a multi-hour task should not require the session to stay open the entire time. Pausing the environment stops billing for compute while preserving the workspace. Resuming restores it to the exact state it was in. ## How to run a coding agent in the cloud with Northflank Cloud Harnesses Northflank Cloud Harnesses are pre-configured cloud environments for running coding agents. Each Harness includes a microVM-isolated workspace, SSH access, agent tooling, and optional Git integration. You create a Harness in the Northflank dashboard, connect to it via SSH, and run the agent as you would locally. **Northflank handles the infrastructure around the coding agent, so you do not need to provision and maintain a VM, container environment, networking, storage, and remote access yourself.** You configure the workspace, connect your repository and agent, and start working from the Northflank dashboard or your local terminal. ### Prerequisites - A [Northflank account](https://app.northflank.com/signup) - An account or API key for the coding agent you want to use - A [Git integration](https://northflank.com/docs/v1/application/getting-started/link-your-git-account) if you want to connect a repository (optional) ### Step 1: Create a Cloud Harness In the Northflank dashboard, [create a new project](https://northflank.com/docs/v1/application/getting-started/create-a-project) and open **Harnesses**. Select the coding agent you want to use (Claude, Codex, Cursor, OpenCode, Pi), or choose **Bring Your Own Agent**. Give the Cloud Harness a name and select the environment where it should run. ![image.png](https://assets.northflank.com/image_7155c5d8ce.png) ### Step 2: Authenticate your coding agent Under **Authentication**, choose how you want to authenticate the agent. Depending on the agent, you can use an API key or a linked account. If you choose an authentication method that requires an interactive login, you can sign in when you first open the Cloud Harness. ### Step 3: Connect your repository (Optional) Under **Repository**, select an existing repository and branch, create a new repository, or continue without a repository. This gives the coding agent a ready-to-use workspace for working on your code. ### Step 4: Configure the workspace Under **Advanced**, you can configure runtime variables, the runtime image, compute resources, and workspace storage. Choose the resources and runtime configuration based on what your project and coding agent need. You can also configure networking and ports when the agent needs to run or preview an application. ### Step 5: Start working with the coding agent Once the Cloud Harness is created, you can open its terminal and start working with your coding agent. The agent can inspect the repository, modify files, install dependencies, run commands, and test changes from the cloud workspace. ![image 1.png](https://assets.northflank.com/image_1_5c09263173.png) ### Step 6: Access the Cloud Harness from your local terminal You can also connect to the same Cloud Harness from your local machine using SSH. Open the Cloud Harness overview, select **Connect** under **Local access**, copy the generated command, and run it with the Northflank CLI ([install and authenticate the CLI](https://northflank.com/docs/v1/api/use-the-cli)). This gives you a familiar terminal workflow while the coding agent and its workspace continue running in the cloud. ![image 2.png](https://assets.northflank.com/image_2_92639c0f91.png) ### How to manage Northflank Cloud Harnesses You can manage networking, environment variables, resources, and storage for your Cloud Harness. You can also pause, resume, and delete Cloud Harnesses as needed. You can update the configuration without losing your workspace files. See the [official guide to configuring and managing Cloud Harnesses](https://northflank.com/docs/v1/application/cloud-harness/configure-and-manage-cloud-harnesses). ## FAQ: running coding agents in the cloud ### What is a cloud coding agent? A cloud coding agent is a coding agent that runs in a remote cloud environment rather than directly on your local machine. The agent can access a repository, execute commands, modify files, run tests, and use development tools from its cloud workspace. The coding agent is responsible for reasoning and using tools, while the cloud environment provides the compute, storage, networking, and workspace where those tools run. ### What is the best way to run a coding agent in the cloud? The right approach depends on the agent and workload, but a dedicated cloud workspace should provide isolated compute, repository access, persistent storage, controlled credentials, networking, and remote access. A managed environment such as a Northflank Cloud Harness provides these resources without requiring you to provision and maintain the underlying infrastructure yourself. ### Can I run Claude Code in the cloud? Yes. Claude Code can run in a cloud workspace such as a Northflank Cloud Harness. You can authenticate Claude Code, connect a repository, configure the workspace, and access it through the Northflank dashboard or SSH. [See the full Claude Code guide](https://northflank.com/blog/run-claude-code-in-the-cloud). ### Can I run Codex in the cloud? Yes. Codex can run in a Northflank Cloud Harness with a connected repository and configured workspace. You can access the environment through the dashboard or connect to it locally using SSH. [See the full Codex guide](https://northflank.com/blog/run-codex-in-the-cloud). ### Is it safe to run a coding agent in the cloud? A cloud environment can provide isolation and infrastructure controls, but security still depends on how the workspace and agent are configured. Limit repository, network, credential, and tool access to what the task requires, and review changes before merging them into production code. A Cloud Harness provides the cloud workspace where an agent runs. The agent may also have its own command or tool sandbox, and these controls should be treated separately. ## Related articles - [How to run Claude Code in the cloud](https://northflank.com/blog/run-claude-code-in-the-cloud) - [How to run Codex in the cloud](https://northflank.com/blog/run-codex-in-the-cloud) - [What is an AI agent harness?](https://northflank.com/blog/what-is-an-agent-harness)

What are cloud coding agents?

2026-09-28T16:00:00.000Z

## TL;DR: what are cloud coding agents? - A **cloud coding agent** is an AI coding agent that runs in a remote cloud environment instead of directly on your local machine, with the compute, storage, tools, networking, and credentials it needs to work on a codebase. - Running coding agents in the cloud gives them isolated, persistent workspaces with dedicated resources, so they can continue working when you disconnect and stay separate from your local development environment. - [Northflank Cloud Harnesses](https://northflank.com/docs/v1/application/cloud-harness/quickstart) provide the infrastructure for running coding agents in the cloud, with support for Claude Code, Codex, Cursor, OpenCode, Pi, or bring your own agent. Harnesses can run on [Northflank's managed cloud](https://northflank.com/features/managed-cloud), in your own AWS, GCP, Azure, Oracle, or CoreWeave account through [self-serve BYOC](https://northflank.com/features/bring-your-own-cloud), giving teams control over where their coding environments run. > [Run your first coding agent in the cloud with Northflank Cloud Harnesses](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your team’s setup. > A cloud coding agent is a coding agent that runs in a cloud environment rather than on a local machine. The agent receives tasks, generates and executes code, reads and writes files, and interacts with repositories inside an isolated workspace hosted on remote infrastructure. The actual coding work happens in the cloud, while you can connect to and manage the environment from your local machine. Cloud coding agents can continue working when you disconnect and retain their workspace between sessions. This article explains what cloud coding agents are, how they differ from local agents, what they consist of, how they work, and where they run. ## What is a cloud coding agent? A **cloud coding agent** is an AI coding agent that executes inside a cloud-hosted environment rather than directly on a developer’s local machine. It can receive a task, inspect a repository, generate and modify code, run commands, install dependencies, and execute tests inside that remote environment. What makes it a cloud coding agent is where the work is executed. The agent’s repository, filesystem, development tools, and runtime are hosted in a cloud workspace rather than on the developer’s laptop. The developer can still connect to and manage the workspace remotely, but the agent has its own environment and resources for carrying out coding tasks. ## How is a cloud coding agent different from a local coding agent? The main difference between a cloud coding agent and a local coding agent is where the agent executes its work. A local coding agent runs directly on your computer and uses your local files, CPU, memory, network connection, credentials, and development tools. A cloud coding agent runs inside a remote environment with resources allocated specifically to the agent. | | Local coding agent | Cloud coding agent | | --- | --- | --- | | Execution | Runs on your local machine | Runs in a remote cloud environment | | Compute | Uses your computer's resources | Uses dedicated cloud resources | | Storage | Local filesystem | Cloud storage or persistent volumes | | Isolation | Shares your machine environment | Can run in an isolated workspace | | Access | Usually tied to your machine | Can be accessed remotely | | Long-running tasks | Require your machine to stay available | Can continue running after you disconnect | | Scaling | Limited by local hardware | Resources can be configured for the workload | | Infrastructure | Managed by the developer | Can be managed by a cloud platform | A local environment can be convenient for interactive development because everything the agent needs is already on your machine. Cloud environments become more useful when you need persistent workspaces, additional compute, stronger isolation, remote access, or the ability to run multiple agents independently. ## What does a cloud coding agent consist of? A cloud coding agent has five main components working together. - **The model:** The language model receives the task and determines the next action. For example, Claude Code uses Anthropic's Claude models, while Codex uses OpenAI models. The model runs on the provider's infrastructure and is separate from the cloud environment where the agent executes its work. - **The tool layer:** The agent uses tools to perform actions such as running shell commands, reading and writing files, interacting with Git, installing packages, and running tests. The tool layer connects the model's decisions to real operations inside the workspace. - **The execution environment:** This is the cloud workspace where the agent actually operates. It provides the operating system, development tools, repository, filesystem, and resources needed to run the code. On Northflank, this environment is provided through Cloud Harnesses, which give coding agents an isolated cloud workspace. - **Secrets and credentials:** The agent may need credentials to access the model, Git repositories, APIs, package registries, or other services used by the application. These credentials need to be made available to the workspace without exposing them in the codebase. - **State and persistence:** The workspace needs a way to retain files, dependencies, Git history, and other state between sessions. Persistent storage allows an agent to stop and resume work without starting from a clean environment each time. **On Northflank, this execution environment is provided through [Cloud Harnesses](https://northflank.com/docs/v1/application/cloud-harness/quickstart)**, which give coding agents isolated, persistent cloud workspaces with configurable compute, storage, networking, and remote access. ## How do cloud coding agents work? When a developer starts a cloud coding agent, the agent runs inside a cloud workspace with access to the repository, development tools, and resources it needs. The developer gives the agent a task, and the agent works through that task inside the remote environment. The agent typically follows an execution loop: 1. **Read the task and context:** The agent inspects the repository, relevant files, test output, error logs, and other available context. 2. **Call the model:** The agent sends the task and relevant context to the model, which determines the next action. 3. **Execute the action:** The agent uses its tools to run commands, edit files, install dependencies, interact with Git, or perform other operations inside the cloud workspace. 4. **Observe the result:** The output from the action, such as command output, file changes, or test results, is added to the agent's context. 5. **Continue the loop:** The agent sends the updated context back to the model and determines the next action. It continues until the task is complete, fails, or is stopped. The important distinction is that the agent's **execution happens inside the cloud workspace**. Your local machine can be used to connect to and manage the workspace, but it does not need to provide the compute, filesystem, or development environment where the agent performs its work. ## Why run coding agents in the cloud? - **Isolation from your local machine:** When a coding agent runs locally, it operates within your local development environment and may have access to files, credentials, processes, and other projects available to it. In the cloud, the agent can run inside a separate workspace with its own filesystem, credentials, and network configuration. This helps limit the agent's access to your local environment and reduce the potential impact of mistakes or unexpected behaviour. - **Persistence across sessions:** A cloud workspace can persist after you disconnect from the agent. You can stop working and return later with the same files, Git history, dependencies, and configuration. This makes cloud environments useful for long-running coding tasks that do not need to be tied to an open terminal or laptop. - **Dedicated compute:** Cloud coding agents can run with CPU, memory, storage, and other resources configured for the workload. The agent does not have to compete with your local development tools for resources, and you can provision more capacity when a task requires it. - **Run multiple agents independently:** Each coding agent can run in its own workspace with its own repository state, dependencies, and resources. This makes it easier to run multiple coding tasks in parallel without their environments interfering with one another. With Northflank, teams can create multiple Cloud Harnesses and run them simultaneously on Northflank's managed cloud or inside their own VPC through BYOC. - **Run agents in your own cloud:** Teams with specific infrastructure, networking, or data requirements can run coding agent environments in their own cloud infrastructure. With BYOC, the execution environment can run inside your existing cloud account while still being managed through the same platform. ## Where do cloud coding agents run? Cloud coding agents can run in different types of cloud environments, including virtual machines, containers, sandboxes, and microVM-based workspaces. The right environment depends on the level of isolation, resource control, persistence, and infrastructure access the agent requires. For coding agents, the execution environment needs to provide more than compute. It needs a filesystem, development tools, repository access, networking, credentials, and a way to persist the workspace between sessions. Managed cloud workspaces package these requirements into an environment that can be created and configured specifically for coding agents. **Northflank Cloud Harnesses provide this type of managed cloud workspace.** Each Harness provides an isolated environment with configurable resources, persistent storage, remote access, and coding agent tooling. Harnesses can run on Northflank's managed infrastructure or in your own cloud through BYOC. ## What does a cloud coding agent need? A cloud coding agent needs an execution environment that gives it the resources and access required to complete coding tasks. The exact requirements depend on the agent and workload, but most cloud coding environments need the following: 1. **An isolated execution environment:** The agent needs a workspace separated from the host system and other workloads. This gives it a controlled environment where it can execute code, install dependencies, and run commands. 2. **Repository access:** Most coding agents work against a Git repository. The workspace needs access to the repository and the credentials required to clone, pull, commit, and push changes. 3. **Agent credentials:** Coding agents need credentials to access their underlying model and any external services required by the project. These credentials should be stored securely and injected into the environment at runtime rather than included in the codebase. 4. **Development tooling:** The workspace needs the tools required by the project, including a shell, language runtimes, package managers, build tools, and test runners. These can be pre-installed or installed by the agent when needed. 5. **Configurable compute:** Different coding tasks have different resource requirements. A large build or test suite may need more CPU and memory than a small code change, so the workspace should allow resources to be configured around the workload. 6. **Networking:** The agent may need network access to clone repositories, download packages, call APIs, access databases, and interact with other services. Network access should be configurable based on the workload and security requirements. 7. **Remote access:** Developers need a way to connect to the workspace and interact with the agent. This can include SSH, a web interface, or other remote development tools. 8. **Persistent storage:** The workspace needs persistent storage if work should survive between sessions. This allows files, dependencies, Git history, and other state to remain available when an agent is paused and resumed. ## How Northflank runs cloud coding agents Northflank Cloud Harnesses provide the infrastructure needed to run coding agents in isolated cloud workspaces. Each Harness gives the agent a configured execution environment with compute, storage, development tools, remote access, and persistent workspace state. You can create a Harness from the Northflank dashboard, connect to it remotely, and run a coding agent in the same way you would locally. Cloud Harnesses support different coding agents, so you can run agents such as Claude Code, Codex, OpenCode, Cursor, and Pi, or configure your own coding agent with Bring Your Own Agent. Each workspace can be configured with the resources, storage, networking, and credentials the agent needs for its task. ![image.png](https://assets.northflank.com/image_7155c5d8ce.png) Harnesses run in isolated microVM environments and can be deployed on Northflank's managed cloud or in your own cloud through BYOC. This lets teams choose between managed infrastructure and running their coding agent environments inside their existing AWS, GCP, Azure, Oracle, or CoreWeave infrastructure. If you want to start running coding agents in the cloud, see our guide on [how to run a coding agent in the cloud](https://northflank.com/blog/how-to-run-coding-agents-in-the-cloud). You can also follow the dedicated guides for [Claude Code](https://northflank.com/blog/run-claude-code-in-the-cloud) and [Codex](https://northflank.com/blog/run-codex-in-the-cloud). ## FAQ: w**hat are cloud coding agents?** ### What is the difference between a coding agent and a cloud coding agent? A coding agent is an AI agent that can write, edit, and execute code using tools. A cloud coding agent is a coding agent whose execution environment runs in the cloud rather than on the developer’s local machine. The model may be hosted remotely in both cases, but the key difference is where the agent’s tools, filesystem, repository, and runtime execute. ### What are the benefits of running a coding agent in the cloud? Running a coding agent in the cloud can provide an isolated workspace, persistent storage, dedicated compute, remote access, and configurable resources. It also allows agents to continue working without keeping a local machine running and makes it easier to run multiple agents in separate environments. ### Can multiple coding agents run in the cloud at the same time? Yes. Cloud infrastructure can provide separate workspaces for different coding agents or tasks. Each workspace can have its own repository, dependencies, resources, credentials, and configuration, allowing agents to work independently without interfering with one another. ### Where can cloud coding agents run? Cloud coding agents can run in virtual machines, containers, sandboxes, microVMs, or managed cloud workspaces. The appropriate environment depends on the workload and requirements for isolation, resource control, persistence, networking, and infrastructure ownership. ### Which coding agents can run in the cloud? Most coding agents that can run from a command line or development environment can also run in the cloud if their runtime and authentication requirements are available. This includes agents such as Claude Code, Codex, OpenCode, and Pi. Northflank Cloud Harnesses also support Bring Your Own Agent, allowing you to configure other coding agent CLIs in a cloud workspace. ## Related articles - [What is an agent harness?](https://northflank.com/blog/what-is-an-agent-harness) - [How to run a coding agent in the cloud](https://northflank.com/blog/how-to-run-coding-agents-in-the-cloud) - [How to run Claude Code in the cloud](https://northflank.com/blog/run-claude-code-in-the-cloud)

What is an AI agent harness?

2026-09-25T15:32:00.000Z

## TL;DR: What is an AI agent harness? An AI agent harness is the software that connects an AI model to tools, supplies context, tracks task state, and manages the loop between model requests and tool results. It enables an agent to take actions and use their outcomes to continue a task across multiple steps. - **Tools and context:** Make relevant information and actions available to the model, then return tool results for the next step. - **State and recovery:** Track progress and retain the information needed to continue after an interruption. - **Permissions and stopping rules:** Apply configured action limits, request approval where needed, and end or pause the run. - **Execution:** Connect tools to the environment where they operate. The harness and its tools can run locally or in the cloud; isolation depends on that environment. To run coding agents in a shared, isolated cloud environment, [set up a Northflank Cloud Harness workspace](https://northflank.com/docs/v1/application/cloud-harness/quickstart) and connect your repository. [Get started with Northflank](https://app.northflank.com/signup), or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your team’s setup. ## What is an AI agent harness? An AI agent harness coordinates the software around a model so it can use tools and work through a task. It prepares model inputs, routes tool requests, returns results, and manages whether the run continues, pauses, or stops. For example, a model can propose a code change. The harness lets the agent read the relevant files, apply the change through a tool, run tests, and use any failures to decide what to try next. Permissions, recovery, and stopping rules depend on how the harness is implemented and configured. ## How is an AI agent harness different from a model or agent? The model generates responses and proposes actions. The harness prepares its inputs, coordinates tool execution, and tracks the run. The agent is the working system that uses those capabilities to pursue a task. For example, when a model requests a file read, the harness routes that request to a tool and returns the contents. The model does not read the file simply by naming it. This distinction helps you separate a proposed action from an action that actually happened. ## What does an AI agent harness include? An agent harness connects a model to the tools, context, and execution environment it needs to complete a task. Check which components your chosen harness includes. | Component | Responsibility | Example | | --- | --- | --- | | Model interface and loop | Send requests and continue or stop the run | Ask for another action after a test fails | | Context management | Select the information available to the model | Load relevant files and summarize earlier work | | Tool layer | Expose operations and validate their inputs | Read a file or call an approved API | | Execution environment | Provide the resources where operations run | Execute tests in an isolated workspace | | State and persistence | Retain information needed to continue | Save task progress and artifact references | | Permissions and intervention | Apply action rules and request help when needed | Require approval before a production change | | Evaluation and telemetry | Check outcomes and record observable activity | Associate test results with a run and code revision | ## How does an AI agent harness work? An AI agent harness works through an [agent loop](https://code.claude.com/docs/en/how-claude-code-works): it gives a model context, executes permitted actions, and feeds results back until the run reaches a stopping condition. A run typically follows these steps, sometimes executing independent tools concurrently. ### 1. Load the task and relevant context The harness prepares the model's input from the user's request, system instructions, available tools, and relevant task information. For coding, context might include repository instructions, selected files, and previous test output. Let the agent retrieve additional information as needed instead of loading every file into the prompt. Define the expected result early. “Fix pagination without changing the response schema” gives the run a more useful completion condition than “improve this API.” ### 2. Request the next action The model returns a response or a tool request identifying an operation and its arguments, such as a file path or shell command. ### 3. Check permissions and execute A harness with permission controls checks each requested action against its configured rules, then allows it, blocks it, or asks for approval. Validate tool arguments and restrict access both where the code runs and in the services it calls. A prompt asking the model to avoid production cannot replace a credential that lacks production access. Keep policy administration and emergency shutdown outside the agent's writable workspace. If developers need to inspect an app while an agent works, Northflank provides [Cloud Harness networking settings](https://northflank.com/docs/v1/application/cloud-harness/configure-and-manage-cloud-harnesses#configure-networking) with public or private ports. Choose a private port for internal access or a public port when the app needs to be reachable over the internet. ### 4. Return observations to the model The tool returns file contents, an API response, or command output. The harness adds relevant results to the next model request. A failing test can change the next action. The agent may inspect another function, revise its patch, or ask for missing information. Keep output bounded and treat retrieved content as task data. A repository file or tool response should not be able to grant new permissions simply by containing instructions. ### 5. Preserve progress across interruptions Longer tasks need a way to retain progress when context fills up or execution stops. Depending on the implementation, this can involve conversation summaries, saved task state, progress files, commits, and references to outputs. Keep track of what the model can currently see, what the application has saved, and what remains in the workspace. Restoring one does not automatically restore the others. If your team needs to stop compute between coding sessions, Northflank provides [Cloud Harness pause and resume](https://northflank.com/docs/v1/application/cloud-harness/configure-and-manage-cloud-harnesses#pause-and-resume-a-cloud-harness). Files under `/home/harness` survive, while terminal sessions and processes stop. When you return, restart the processes you need and use your coding agent's session recovery if it supports it. ### 6. Check completion and close the run The harness ends the loop when the agent finishes, a limit is reached, a failure prevents progress, or a user cancels it. Before accepting a completion message, inspect the evidence. Review code changes and test results, or check that a data-processing result accounts for the input records. Record the final status and retained artifacts, then apply your workspace and credential cleanup policy. For the wider execution architecture, see [what infrastructure AI agents need to run code safely](https://northflank.com/blog/ai-agent-code-execution-infrastructure). ## What does an AI agent harness look like in practice? A coding agent fixing a pagination bug shows how the model, harness, and environment work together. Suppose your task is to correct an endpoint that repeats the last item of one page at the start of the next. The agent may edit the relevant code and tests, but has no production credentials. The harness makes repository-reading and test-execution tools available. The model requests the endpoint and its tests, then proposes a regression test. Running that test produces a failure showing the duplicate item. The harness returns the result, and the model uses it to propose a patch. After the patch, the agent reruns the tests and reports the changes, results, and any unfinished work. Review the fix against the task requirements before accepting it. Deployment follows your release policy. If your team needs to connect reviewed changes to builds and releases, Northflank provides [Workflows](https://northflank.com/docs/v1/application/release/configure-workflows) with build, deployment, condition, and approval nodes. ## How is an AI agent harness different from a framework or sandbox? An agent harness coordinates the working agent, a framework supplies building blocks, and a sandbox provides an isolated place to execute code. These categories overlap. A framework can include a ready-made harness, and a coding product can bundle the model interface, tools, and runtime experience. Check which parts you get out of the box and which your team still needs to build or operate. A sandbox alone does not assemble model context, interpret task progress, or decide when the work is complete. A harness using shell tools still needs an execution boundary appropriate to the code it runs. A cloud harness, such as Northflank Cloud Harness, provides a managed coding workspace with its own resources, networking, and configuration. Your chosen coding agent runs its tool loop in that environment, so cloud workspace management and agent behavior remain separate responsibilities. The [Model Context Protocol (MCP)](https://modelcontextprotocol.io/docs/learn/architecture) connects an AI application to tools and contextual resources through a common interface. A harness can use MCP integrations within its tool layer while retaining responsibility for the overall task loop. ## How do you choose an AI agent harness? Try an agent harness on tasks your team actually performs, including runs that fail or need to be interrupted. Before giving it broader access, check how it handles these situations: - **Task completion:** Does it finish the task and show how it checked the result? Test incomplete work and misleading success messages as well as the happy path. - **Recovery:** Can it continue after interruption without losing necessary state? Check whether retrying an external write could create duplicate effects. - **Authority:** Can your team restrict tools, credentials, destinations, and workspace access? Test malformed arguments and instructions embedded in untrusted content. - **Investigation:** Can you connect a request to its tool calls, execution results, and affected resources? Keep sensitive content out of routine logs. - **Resource control:** Can you bound model use, tool duration, retries, and concurrency? Include workspace runtime and retained storage when estimating costs. Your [AI-agent execution audit trail](https://northflank.com/blog/ai-agent-code-execution-audit-trail) should distinguish proposed actions, permitted actions, and observed effects. A terminal transcript alone leaves gaps in that explanation. Choose an existing harness when its tools and behavior fit the task. Build custom orchestration when your application needs a different interaction or control model. In either case, decide separately who will operate the execution environment. For product recommendations, compare the [best AI agent harnesses](https://northflank.com/blog/best-ai-agent-harnesses-for-enterprise-teams). ## How does Northflank support AI agent harnesses? [Northflank Cloud Harness](https://northflank.com/docs/v1/application/cloud-harness/quickstart) gives developers and teams secure, isolated cloud workspaces for coding agents. It suits teams that want agents to work on repositories away from local machines, keep files between sessions, and collaborate in the same environment. Northflank manages the workspace infrastructure; your chosen agent manages model calls and the tool loop. You can run agents such as Claude Code, Codex, Cursor, OpenCode, and Pi, or bring your own agent. Connect your agent account or API key and a repository, then access the workspace through the dashboard or SSH. ![codex-harness.webp](https://assets.northflank.com/codex_harness_45ada44f09.webp) The [Cloud Harness settings](https://northflank.com/docs/v1/application/cloud-harness/configure-and-manage-cloud-harnesses) let you configure its software environment, compute, storage, and environment variables, and monitor CPU and memory usage. ![monitor-harness.webp](https://assets.northflank.com/monitor_harness_b5bf77c9ab.webp) Run workspaces on [Northflank’s managed cloud](https://northflank.com/cloud/northflank) or use [bring your own cloud (BYOC)](https://northflank.com/docs/v1/application/bring-your-own-cloud/use-other-cloud-providers-with-northflank) to run them in your own cloud account. You own the cloud resources; Northflank provisions and manages Kubernetes. Your team still configures agent credentials, tool permissions, and review requirements. If you are building an agent application that needs to create execution environments programmatically, [Northflank Sandboxes](https://northflank.com/docs/v1/application/sandboxes/quickstart) provides that capability, including deployment in [your own cloud account and VPC](https://northflank.com/docs/v1/application/sandboxes/sandboxes-in-your-own-cloud). [Set up a Cloud Harness workspace](https://northflank.com/docs/v1/application/cloud-harness/quickstart), connect your repository, and run a coding task in the cloud. [Get started with Northflank](https://app.northflank.com/signup), or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your coding-agent workflow and infrastructure requirements. ## Frequently asked questions about AI agent harnesses Start with a simple loop and add controls as tasks require them. ### Is a prompt enough to create an AI agent harness? A prompt supplies instructions. Software must still call the model, execute tools, return results, and manage the run. A small application can implement that loop, but the prompt alone does not perform it. ### Does an AI agent harness make an agent autonomous? It enables repeated action without requiring a new user message at every step. You control how much it can do through its tools, permissions, stopping conditions, and opportunities for human intervention. It does not guarantee successful task completion. ### Does an AI agent harness need multiple agents? No. One model-driven loop can handle a multistep task. Add delegation when separate work benefits from its own context or parallel execution, and account for the extra coordination and resource use. ### Can an AI agent harness run locally? Yes. A harness can run on a local machine, a remote server, or managed cloud infrastructure, depending on the product. Running the harness locally does not necessarily mean the model runs locally. Check where tool execution, stored state, and model requests go. ### What is harness engineering? Harness engineering is the work of designing and improving the software around a model: tool interfaces, context handling, state, controls, and evaluation. It changes how the agent operates without necessarily changing the model's weights. ## Related articles about AI agent harnesses and code execution Continue with these guides to the infrastructure and controls around agent workflows: - [What infrastructure do AI agents need to run code safely?](https://northflank.com/blog/ai-agent-code-execution-infrastructure) - [What should an audit trail for AI-agent code execution contain?](https://northflank.com/blog/ai-agent-code-execution-audit-trail) - [How to deploy coding agents at scale](https://northflank.com/blog/deploy-coding-agents-at-scale) - [How to give your AI agent a secure computer](https://northflank.com/blog/give-ai-agent-secure-computer)

Best code execution APIs for AI agents in 2026

2026-09-25T15:30:00.000Z

## TL;DR: Best code execution APIs for AI agents in 2026 The best code execution API for your AI agent depends on what it needs to run, which results it needs back, how code is isolated, and what state must survive between calls: 1. **Northflank:** Best for AI agents that need a code execution API to run AI-generated scripts, test code changes, and start development servers for application previews. Its API supports JavaScript and Python SDKs for isolated code execution, streamed command output, execution results, and sandbox lifecycle controls. 2. **E2B:** Best for AI agents that need a stateful code interpreter API. Python and JavaScript/TypeScript clients execute snippets, reuse variables within a context, and return text, charts, and other rich results. 3. **Modal:** Best for agents combining process execution with GPU tasks. Its execution API provides process input/output streams through Python, with JavaScript/TypeScript and Go SDKs also available in beta. 4. **Vercel:** Best for AI coding agents that build applications and expose previews. Its command API supports completed or detached execution, streamed logs, and exit results, with JavaScript/TypeScript and Python SDKs. 5. **Blaxel:** Best for AI agents that need a process execution API for named tasks across client requests. Its API supports status checks and streamed logs, with keep-alive controls when work must continue during a disconnect; standby preserves memory and files while suspending execution. To evaluate code execution for your AI agent, follow the [Northflank quickstart](https://northflank.com/docs/v1/application/sandboxes/quickstart) to run your first command through the API. [Get started](https://app.northflank.com/signup) to test your agent’s execution workflow, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss isolation, networking, and running agent sandboxes in production. Choosing a code execution API for AI agents starts with the tasks your agent needs to perform, such as analyzing data, running scripts, installing dependencies, testing generated code, or starting application previews. Your application needs to submit work, interpret the response, and recover when execution or the connection fails. This guide compares code execution APIs for AI agents from Northflank, E2B, Modal, Vercel, and Blaxel, explaining where each platform fits and how its API handles execution, results, streaming, state, and recovery. It also covers supported SDKs and the programming languages you can use to call each API, isolation, deployment options, and cost considerations. ## What is a code execution API for AI agents? A code execution API is the interface your application calls to run code and retrieve results. A sandbox is the isolated environment where that code runs. The services below expose execution APIs backed by sandboxes, but the two terms describe different parts of the integration. A **command interface** starts a process, such as a test runner, package installer, or development server. Your application handles its output and eventual exit status. A **code interpreter interface** executes snippets in a language context and can retain variables between calls. An agent analyzing a dataset may need an interpreter; an agent building a repository usually needs command and file operations. Agent-oriented SDKs connect these operations to an agent’s tool calls: create an environment, execute code, return results, and continue or clean up. The useful distinction is how much execution and lifecycle handling the SDK provides for your workflow. The SDK language is another separate choice. A Python client can execute JavaScript or shell commands when the remote environment contains those runtimes. Check both the client library and the image or interpreter your code will use. ## How do code execution APIs compare for AI agents? Compare the execution call and its response before choosing an environment. A completed result, a running process handle, and an interpreter result require different logic in your agent’s tool handler. | Platform | Client language / SDK | Execution model | Results and streaming | Isolation | | --- | --- | --- | --- | --- | | Northflank | JavaScript and Python | Commands and interactive sessions | Streamed output, status, and exit codes | MicroVMs (Kata Containers with Cloud Hypervisor; Firecracker where supported) and gVisor | | E2B | Python and JavaScript/TypeScript | Reusable interpreter contexts | Output, errors, charts, and text | Firecracker-based microVMs | | Modal | Python; JavaScript/TypeScript and Go in beta | Interactive processes | Streamed output or completed results | gVisor; CPU-only VM Sandboxes also available in beta | | Vercel | JavaScript/TypeScript and Python | Completed or background commands | Streamed logs and exit status | Firecracker microVMs | | Blaxel | TypeScript, Python, and Go | Named processes across requests | Status, streamed logs, and completion results | MicroVMs | The SDK language and result format affect integration; isolation describes the execution environment behind the API. Network access and credentials still need controls appropriate to the task. ## Which APIs should you consider for AI agent code execution? The five platforms below provide code execution APIs for different AI-agent workflows, including running commands, interpreting code, using GPUs, building application previews, and managing processes across requests. Each combines code execution with environment management, but their interfaces and retained state differ. ### 1. Northflank Northflank provides a code execution API that AI-agent applications can call to run AI-generated code in isolated sandboxes, install dependencies, test changes, and start development servers. GPU-backed sandboxes also support agent tasks that need accelerated computation. - **SDKs for agent tool calls:** JavaScript and Python SDKs let an application execute code, receive results, and manage sandbox lifecycles across an agent’s tool calls. - **Streamed output and execution results:** The [command execution API](https://northflank.com/docs/v1/application/sandboxes/quickstart) returns progress and completion results to guide an agent’s next step. Interactive sessions also accept input while commands run. - **Workspace continuity and file persistence:** Successive calls can use the same workspace. [Pausing](https://northflank.com/docs/v1/application/sandboxes/configure-and-manage-sandboxes) preserves attached-volume files, but stops processes and discards ephemeral files; commands need restarting after resume. - **Isolation:** On [Northflank Cloud](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank-cloud), CPU sandboxes run in microVMs and GPU sandboxes use gVisor, with isolation enabled automatically. - **Deployment options:** [Northflank Sandboxes](https://northflank.com/product/sandboxes) run on managed infrastructure or through [bring your own cloud (BYOC)](https://northflank.com/features/bring-your-own-cloud), with Northflank as the control plane, provisioning and managing Kubernetes for agent sandboxes in your VPC. A sandbox can host the agent itself or the code it executes. Your own cloud requires a supported isolation runtime. Orchestration metadata is handled separately from execution. - **Team collaboration and API access:** [Roles and permissions](https://northflank.com/docs/v1/application/secure/use-role-based-access-control) let teams manage agent environments together while controlling resource access through the dashboard and API. To get started with Northflank’s code execution API, follow the [quickstart guide](https://northflank.com/docs/v1/application/sandboxes/quickstart) to run code in an isolated sandbox. [Create an account](https://app.northflank.com/signup) to test your AI agent’s workflow with self-serve access, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss production requirements for isolation, networking, and sandbox deployment. **Best for:** AI agents that need a code execution API for scripts, tests, and development servers, with control over where their sandboxes run. ### 2. E2B E2B provides a code interpreter API that AI-agent applications can call from Python or JavaScript/TypeScript. It suits analysis workflows where an agent submits code, examines the result, and builds on earlier calculations. - **Variables retained between calls:** Code contexts retain variables and imports, allowing an agent to load a dataset once and explore it across several calls. Restarting the context clears that state. - **Results:** Its [streaming interface](https://docs.e2b.dev/code-interpreting/streaming) separates execution logs, runtime errors, and results such as charts, tables, and text. - **Memory and filesystem persistence:** Normal pause preserves memory and files, while filesystem-only pause does not retain variables in memory. Workflows that depend on earlier calculations need a way to reconstruct them when that state is lost. - **Isolation:** Each sandbox uses a Firecracker-based microVM with its own kernel for agent code execution. **Best for:** AI agents that need a stateful code interpreter API for iterative data analysis and rich results. ### 3. Modal Modal’s sandbox execution API lets AI-agent applications run generated code and interact with it while it executes. GPU access makes it relevant to agents whose tasks include accelerated computation. - **Interactive process execution:** The [command execution interface](https://modal.com/docs/guide/sandbox-spawn) lets an application stream output, send input, or wait for a finished result. This suits agents following a longer computation or working with a process that needs further input. - **Python, JavaScript/TypeScript, and Go SDKs:** Python is Modal’s primary application language. Its JavaScript/TypeScript and Go SDKs also support sandboxes, though they remain in beta without full Python feature parity. - **State and recovery for longer tasks:** A running sandbox retains its working environment, with continuous lifetime capped at 24 hours. GPU workloads can also be preempted. Saved files or checkpoints let an agent continue in a replacement environment instead of repeating all its work. - **Isolation:** Standard sandboxes use gVisor. VM Sandboxes provide a separate Linux kernel in beta and currently support CPU workloads only. **Best for:** AI agents that need a process execution API with interactive input and output, particularly for GPU-backed tasks. ### 4. Vercel Vercel provides command and file operations for AI coding agents through Vercel Sandbox, with JavaScript/TypeScript and Python SDKs. Its execution model fits the progression from generating an application to building it and showing a working preview. - **Build commands and preview servers:** The [command API](https://vercel.com/docs/sandbox/sdk-reference) can wait for a completed result or let work continue in the background. Applications can stream logs and retrieve the final exit status, giving an agent feedback on a build while a preview server remains available. - **Execution tracking across requests:** A command identifier lets the application retrieve an earlier execution. That helps it follow ongoing work across requests, although the application still needs to determine when a preview server is ready. - **Filesystem persistence across sessions:** Persistent sandbox sessions retain repository changes and installed files through filesystem snapshots, while background services need restarting. Snapshots expire 30 days after last use by default; the 45-minute Hobby and 24-hour Pro/Enterprise limits apply to individual running sessions. - **Isolation:** Each sandbox runs in a Firecracker microVM with its own filesystem and network. **Best for:** AI coding agents that need a command execution API to build applications and provide interactive previews. ### 5. Blaxel Blaxel, now part of Baseten, provides a process API for AI agents whose tasks span multiple client requests. An application can start a named process, disconnect, and later return to check its progress. - **Process status and streamed logs:** The [process execution API](https://docs.blaxel.ai/Sandboxes/Processes) supports TypeScript, Python, and Go integrations, with operations for checking status, streaming logs, and waiting for completion. Named processes help an application inspect earlier work before starting a replacement. - **Background execution controls:** Waiting for a response and keeping execution active are separate choices. Keep-alive prevents standby while a process runs; without it, a disconnected task can be suspended. A client wait timeout alone does not necessarily stop the process. - **Memory and filesystem persistence:** The standby lifecycle retains memory and files while suspending execution. An agent can return to its working state, although connections to databases or other external services may need restoring. - **Isolation:** Each sandbox runs in its own microVM with a separate kernel. **Best for:** AI agents that need a process execution API for tasks they revisit across requests, with control over whether work continues during a disconnect. ## How do you connect a code execution API to an AI agent? A backend tool handler connects the model to the execution API. It authorizes tasks, keeps provider credentials outside generated code, creates or reconnects to environments, and returns results to the agent. Save environment and process identifiers where available. Return status, bounded output, command exit codes or interpreter errors, and artifact references in a consistent format. Stderr alone does not mean failure. A request timeout does not necessarily stop remote execution. Check the original task before retrying work with side effects. Save required files before cleanup, and stop, pause, or delete environments when work finishes. ## Which execution API fits your AI agent’s production workload? Choose the service whose response and recovery model fits your agent’s workflow, then validate it with a representative task. Include a failing command, an interrupted connection, a long-running process, file retrieval, and cleanup. Check concurrent sandbox limits and environment-creation rates separately, using the plan you would actually deploy. Verify that your dependencies, file operations, and any agent-framework integration fit the execution environment. Northflank is the default recommendation for teams that need a code execution API for AI agents to run AI-generated scripts, test code changes, and launch application previews in isolated sandboxes. For an interpreter-heavy workflow, prioritize context and rich-result handling; for builds and servers, prioritize process identifiers, streaming, readiness, and termination. Measure time to useful output with your real dependencies. Test fresh creation and resume separately; they measure different stages of execution. Compare cost per completed agent task, including setup, execution, retries, and retained storage. The decisive question is whether your application can determine what happened and continue safely when a call fails. To try Northflank’s code execution API with your AI agent, follow the [quickstart guide](https://northflank.com/docs/v1/application/sandboxes/quickstart) and [create an account](https://app.northflank.com/signup) for self-serve access. For production planning, [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss isolation, networking, and deployment requirements. ## Frequently asked questions about code execution APIs for AI agents ### Should I use a code execution API or a built-in code interpreter for my AI agent? A built-in code interpreter can suit an AI agent whose tasks fit its supported languages, packages, and session limits. Northflank, E2B, Modal, Vercel, and Blaxel provide separate code execution APIs for AI agents, with different approaches to commands, interpreter sessions, and background work. A separate API is useful when your application needs execution or deployment controls beyond the built-in interpreter. ### Which programming languages can AI agents run through code execution APIs? AI agents can run languages such as Python, JavaScript, TypeScript, and Bash through code execution APIs, depending on the provider and environment. Command execution APIs from Northflank, Modal, and Vercel can run code using runtimes installed in the sandbox. The available runtimes and dependencies determine which languages a particular environment supports. ### How do code execution APIs isolate AI-generated code? The code execution APIs covered here run AI-generated code inside isolated environments. Northflank Cloud uses microVMs for CPU sandboxes and gVisor for GPU sandboxes; E2B and Vercel use Firecracker-based microVMs. Modal’s standard sandboxes use gVisor, and Blaxel uses microVMs. These boundaries restrict access to surrounding infrastructure, but network permissions, credentials, and resource limits still need controls appropriate to the task. ### Can an AI agent keep files and variables between code execution calls? Yes, but files and in-memory state persist differently. Northflank retains attached-volume files across pause, while its running processes stop. E2B retains variables within interpreter contexts and preserves memory on normal pause; Blaxel preserves memory and files during standby while suspending execution. The right code execution API depends on whether the agent needs saved files, variables, or process state for its next call. ### Can I run an AI agent’s code execution environment in my own cloud? Yes, with a provider that supports customer-cloud deployment. Northflank offers bring your own cloud (BYOC), acting as the control plane to run agent sandboxes inside your cloud account and VPC. Its own-cloud setup requires a supported isolation runtime, and orchestration metadata is handled separately from the execution environment. ## Related articles about AI agent code execution For the infrastructure and lifecycle decisions behind the API: - [Code execution sandboxes for AI agents](https://northflank.com/blog/best-code-execution-sandbox-for-ai-agents) - [Persistent versus ephemeral AI sandboxes](https://northflank.com/blog/persistent-vs-ephemeral-ai-sandboxes) - [AI-agent sandbox security checklist](https://northflank.com/blog/ai-agent-sandbox-security-checklist) - [Deploying an AI agent from sandbox to production](https://northflank.com/blog/how-to-deploy-ai-agent-from-sandbox-to-production)

Best AI agent harnesses in 2026

2026-09-25T15:00:00.000Z

## TL;DR: Best AI agent harnesses in 2026 The best AI agent harness for your team depends on two choices: which agent does the coding, and which platform provides its execution environment and controls. **Cloud AI agent harness platforms:** 1. **Northflank Cloud Harness:** Best for teams that want secure, isolated coding environments for their choice of coding agent, with configurable resources, persistent files, and team collaboration on managed cloud or their own infrastructure. 2. **Coder Agents:** Best for teams that want a self-hosted agent platform with centrally managed model access and development workspaces on their own infrastructure. **Coding harnesses and cloud agents:** 1. **Claude Code:** Best for developers who want Claude to work directly in a codebase, with tools and integrations they can extend through skills, hooks, and MCP. 2. **Codex:** Best for developers using OpenAI's coding agent interactively and teams integrating it into engineering automation. 3. **OpenCode:** Best for developers who want an open-source coding agent with a choice of model providers and configurable tool permissions. 4. **Pi:** Best for developers who want a minimal terminal coding harness they can adapt through extensions, skills, and prompt templates. 5. **Amp Code (Orbs):** Best for teams that want Amp agents to build, run, and test code in isolated remote environments while developers work on other tasks. 6. **Devin:** Best for teams delegating engineering tasks to a cloud coding agent with a shell, editor, and browser. 7. **GitHub Copilot CLI:** Best for developers who want GitHub Copilot to work directly in their terminal, with interactive and scripted coding workflows. > Get started: [Set up a Cloud Harness workspace](https://northflank.com/docs/v1/application/cloud-harness/quickstart), connect your repository, and run your coding agent in the cloud. You can also [deploy in your own cloud account](https://northflank.com/features/bring-your-own-cloud). Choose the coding agent for its tools and behavior, then evaluate where it runs, what state it retains, and how your team controls access. ## What is an AI agent harness? An AI agent harness is the software around a model that manages its tools, context, execution loop, and task state. When an agent reads a repository, edits a file, runs a test, and uses the result to try again, the harness coordinates that work. Products use the term at different levels. Claude Code and Codex provide coding agents you can use directly. Amp Orbs and Devin combine agent capabilities with remote execution environments. Northflank Cloud Harness provides the cloud workspace around your chosen coding harness. It supplies resources, networking, persistent files, and team access so you can run different agents and their supported models in the cloud. You can use Northflank together with Claude Code or Codex; they serve different roles in the same setup. You might select a coding harness and a cloud environment together. The guide to [what an agent harness is](https://northflank.com/blog/what-is-an-agent-harness) explains how the model, tools, and runtime fit together. ## How do the best AI agent harnesses compare? The first table compares platforms for hosting or governing agent execution. The second compares coding harnesses and agents. Some agents include a cloud environment; others can run on a host you choose. **Cloud AI agent harness platforms** | Platform | What you adopt | Best fit | What your team manages | | --- | --- | --- | --- | | Northflank Cloud Harness | Secure, isolated coding environments for your choice of coding agent | Running agents collaboratively with persistent files on managed cloud or your own infrastructure | Agent credentials, workspace configuration, and release approvals | | Coder Agents | Self-hosted platform with a built-in agent loop and centrally governed model access | Running agent tools in workspaces on your infrastructure | Platform operation, workspace templates, model access, and organizational policy | **Coding harnesses and cloud agents** | Harness or agent | What you adopt | Best fit | What your team manages | | --- | --- | --- | --- | | Claude Code | Ready-to-use coding agent with SDK integration options | Working on repositories with Claude's tools and extensibility | Tool access, integrations, and the chosen execution environment | | Codex | Coding agent with CLI and SDK interfaces | Interactive development and programmatic coding tasks | Execution permissions, automation, and job coordination | | OpenCode | Open-source coding agent | Working across model providers with configurable tool access | Provider setup, permission rules, and execution hosts | | Pi | Minimal, extensible terminal coding harness | Building a personalized coding workflow | Extensions, shared configuration, and execution hosts | | Amp Code (Orbs) | Amp agents running in isolated remote machines | Delegating parallel coding tasks without keeping a laptop running | Repository access, environment setup, task instructions, and review | | Devin | Coding agent with a cloud development environment | Delegating fixes, migrations, tests, and other engineering tasks | Repository setup, completion criteria, access, and review | | GitHub Copilot CLI | Terminal coding agent with interactive and programmatic modes | Using Copilot in terminal workflows and scripts | Organizational access, tool permissions, and the execution host | ## Which cloud AI agent harness platforms should you consider in 2026? These platforms address the environment and organizational controls around coding agents. Their approaches differ: Northflank hosts your chosen harness, while Coder Agents includes its own centrally managed agent loop. ### 1. Northflank Cloud Harness [Northflank Cloud Harness](https://northflank.com/docs/v1/application/cloud-harness/quickstart) provides secure, isolated coding environments for running agents such as Claude Code, Codex, OpenCode, Cursor, and Pi, or your own agent. Each workspace has configurable compute, networking, and storage, with access through the dashboard or SSH. With Northflank Cloud Harness, you can run coding agents such as Claude Code, Codex, OpenCode, Cursor, and Pi, or bring your own agent. Connect the model provider or account supported by your chosen harness, so your cloud workspace can support different agent and model combinations as your needs change. Connect your agent account and a code repository, then open the workspace in Northflank’s dashboard or connect from your terminal using SSH. Commands run in the cloud, and teammates can work in the same environment. The [workspace settings](https://northflank.com/docs/v1/application/cloud-harness/configure-and-manage-cloud-harnesses) let you configure its software environment, processing power, memory, storage, and environment variables. When you [pause the workspace](https://northflank.com/docs/v1/application/cloud-harness/configure-and-manage-cloud-harnesses#pause-and-resume-a-cloud-harness), running processes stop, but files in `/home/harness` remain available when you resume. You decide whether applications running in the workspace are publicly accessible or private. Northflank’s [role-based access controls](https://northflank.com/docs/v1/application/secure/use-role-based-access-control) let you define which team members can access and manage resources. Your team still sets the agent’s credentials, tool permissions, and review requirements. Workspaces can run on [Northflank’s managed cloud](https://northflank.com/cloud/northflank) or in [your own cloud account](https://northflank.com/features/bring-your-own-cloud) (AWS, Azure, GCP, etc.). With bring your own cloud (BYOC), Northflank acts as the control plane, managing the infrastructure that runs coding agents and their workspaces in your virtual private cloud (VPC). [Set up a Cloud Harness workspace](https://northflank.com/docs/v1/application/cloud-harness/quickstart), connect your repository, and run your coding agent in the cloud. You can also [deploy in your own cloud account](https://northflank.com/features/bring-your-own-cloud). [Get started with Northflank](https://app.northflank.com/signup), or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your team’s setup. ### 2. Coder Agents [Coder Agents](https://coder.com/solutions/agents) fits enterprise teams that want coding agents to work on their own infrastructure with centrally managed model access. Its built-in agent loop runs in the Coder control plane, while tools execute in connected development workspaces. Administrators can define approved models and providers, including supported private endpoints, and apply usage policies. Model credentials stay in the control plane rather than being placed in each workspace. This gives platform teams a central place to manage model access while agents work against repositories and development tools. For a rollout, your team configures the Coder deployment, workspace environments, model connections, and organizational controls. Coder is a fit when your platform team wants to operate that environment and govern agent access centrally. ## Which coding harnesses and cloud agents should you consider in 2026? These products provide the agent that reads code, makes changes, and uses tools. Choose between an interactive coding workflow and delegated tasks running remotely, then evaluate the execution environment alongside it. ### 1. Claude Code [Claude Code](https://code.claude.com/docs/en/overview) fits developers who want Claude to inspect a codebase, edit files, and run commands as part of an interactive development workflow. It is available through terminal, IDE, desktop, and browser interfaces. Its extensibility is useful when the agent needs project-specific context or tools. Skills provide reusable instructions, hooks run logic at lifecycle events, and Model Context Protocol (MCP) connections give the agent access to external tools. For example, a maintenance workflow could combine repository instructions with a tool that retrieves issue details. If you need that behavior inside an application, [Claude Agent SDK](https://code.claude.com/docs/en/agent-sdk/overview) provides Python and TypeScript libraries with the agent loop, built-in tools, and context management used by Claude Code. An internal service can assign a task and collect the agent's results programmatically. The trade-off depends on the interface you adopt. With the SDK, your application still needs hosting, credential management, and tenant separation. Sessions save to disk automatically, but a worker that can be replaced needs durable storage if those sessions must survive. Evaluate execution placement for the specific interface you plan to use. ### 2. Codex [Codex](https://learn.chatgpt.com/docs/codex/cli) fits developers using OpenAI's coding agent for repository work and teams that want to automate those tasks. Its [CLI](https://learn.chatgpt.com/docs/codex/cli) can inspect code, edit files, and run commands in the environment where you launch it. You can work interactively or use noninteractive execution for automation. A failed-build assistant, for example, could give Codex a repository and failure report, then collect a proposed patch and test results for an engineer to review. Configure execution permissions around the work that assistant should perform. For application integration, Codex SDK provides TypeScript and Python interfaces to local Codex agents. This gives an internal service a way to assign coding work without requiring an engineer to operate every session manually. The trade-off is the infrastructure around automated runs. Your service must coordinate jobs, provide execution hosts, and retain results. If a worker stops after creating a pull request, recovery should check for that existing action before trying again. Running the CLI locally also does not mean the model runs on the same machine; review the model connection separately. ### 3. OpenCode [OpenCode](https://opencode.ai/docs/) suits developers who want an open-source coding agent with a choice of model providers. It supports terminal, desktop, and IDE workflows, so the agent can fit into an existing development setup. Provider choice is useful when different tasks need different models. Keep acceptance criteria consistent when comparing their results. OpenCode's [permission configuration](https://opencode.ai/docs/permissions/) lets you allow, deny, or request approval for tool actions. Rules can be more specific than a blanket permission for an entire tool. A team can use those controls to define which actions proceed automatically and which need a developer's decision. The trade-off is responsibility for the environment and configuration. Your team selects providers, manages credentials, and maintains shared permission rules. Tool approval settings govern agent behavior; they do not by themselves establish process isolation. If the agent can execute code, evaluate the host's filesystem and network access alongside its tool policy. ### 4. Pi [Pi](https://github.com/earendil-works/pi/tree/main/packages/coding-agent) is a minimal terminal coding harness for developers who want to shape their own workflow. It provides coding tools and model-provider choice while allowing customization through [TypeScript extensions, skills, prompt templates, and packages](https://github.com/earendil-works/pi/tree/main/packages/coding-agent). You might package recurring repository instructions as a skill, create a prompt template for maintenance tasks, or add an extension for a team-specific interaction. For a team rollout, decide which customizations belong in a shared configuration and which developers can change individually. Otherwise, two engineers may give the same task to substantially different agent setups, making results harder to reproduce or investigate. The trade-off is the work of assembling and maintaining that setup. Evaluate the extensions you install, pin the versions you depend on, and provide an appropriate execution environment. Pi is a fit when you want that customization responsibility and have a clear reason to take it on. ### 5. Amp Code (Orbs) [Amp Orbs](https://ampcode.com/docs/orbs) are isolated remote machines where Amp agents build, run, and test code. Each orb thread gets its own environment with the repository, tools, and context needed for the task, so work can continue without using your local computer. This fits teams that want to delegate several coding tasks in parallel. A developer can start separate threads for a bug fix, a test update, and a repository investigation, then review the results as they finish. Orbs support sleep and wake while retaining the environment's files and conversation. The cloud environment is part of the Amp workflow, so evaluate how its repository access, setup, and agent behavior fit the way your team assigns and reviews work. ### 6. Devin [Devin](https://docs.devin.ai/get-started/devin-intro) is a coding agent for delegating engineering work, including bug fixes, tests, migrations, and feature development. Its cloud workspace includes a shell, an editor, and a browser, allowing it to change code, run commands, and test applications within the same task. Teams can assign work through its web interface and integrations with tools such as Slack, GitHub, and issue trackers. Developers can follow progress and take over in the editor when a task needs intervention. Devin also provides an API for programmatic workflows. The fit depends on how clearly you can scope and verify delegated tasks. Give it repository context, explicit completion criteria, and tests, then review the resulting changes through your normal engineering process. Evaluate the complete agent-and-workspace workflow when comparing it with a coding harness you host yourself. ### 7. GitHub Copilot CLI [GitHub Copilot CLI](https://docs.github.com/en/copilot/concepts/agents/copilot-cli/about-copilot-cli) brings Copilot into the terminal for repository exploration, code changes, debugging, and GitHub tasks. Developers can work interactively or use programmatic mode to supply a prompt and collect a result in a script. It fits teams that want a terminal coding agent within their existing GitHub workflow. For example, an engineer can ask it to investigate a failing test, propose a fix, and inspect the change before continuing. Organization policies determine whether members can use Copilot CLI, while tool permissions control what it can do during a session. Your team still provides the execution host and decides which files, commands, and services the agent can access. Copilot CLI is the terminal product; GitHub's cloud coding agent is a separate execution option. ## How should you evaluate an AI agent harness? Evaluate a representative task in your own repository, including the environment and review process around it. Use these five checks: 1. **Task quality:** Define the expected change, tests, and review criteria before the run. Record correction time and whether the result was accepted. 2. **Model and harness configuration:** Record the model, tools, instructions, and permissions. Where products support the same model, holding it constant can help you examine harness differences. Otherwise, you are comparing complete setups. 3. **Authority and isolation:** Include an action the agent should be denied. Check tool permissions, filesystem access, network reachability, and credentials separately. 4. **Interruption and recovery:** Stop a run midway through a task. Check which files, conversation state, and external actions survive, then inspect what happens when you resume. 5. **Total cost:** Include model usage, execution time, storage, platform charges, review effort, and maintenance. Compare cost per accepted task, including unsuccessful attempts. For production use, retain evidence that connects the task, changes, tool results, and reviewer decision. The [AI-agent execution audit-trail guide](https://northflank.com/blog/ai-agent-code-execution-audit-trail) explains what a conversation transcript alone can miss. ## Which AI agent harness should you start with? Start with the workflow you already have. For interactive repository work, evaluate Claude Code, Codex, OpenCode, Pi, or GitHub Copilot CLI. For delegated cloud tasks, consider Amp Orbs or Devin. Teams building an internal service should also examine the SDK and state interfaces. Choose Northflank Cloud Harness if your team needs secure cloud coding environments with agent choice, persistent files, and shared access. If your platform team wants to operate a self-hosted environment with a centrally managed agent loop, evaluate Coder Agents. If shared cloud workspaces are your priority, start with one repository on Northflank Cloud Harness. Configure its dependencies and access, run a real task with teammates, and inspect the result before extending the setup across projects. To get started, read the [Cloud Harness docs](https://northflank.com/docs/v1/application/cloud-harness/quickstart) and [create a Northflank account](https://app.northflank.com/signup), or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your team’s deployment requirements. ## Frequently asked questions about AI agent harnesses Use these distinctions to narrow your shortlist. ### Which AI agent harnesses are open source? OpenCode and Pi are options in this shortlist for developers who want an open-source coding harness. Open-source availability does not make model usage, hosting, or operations free. Review the licenses of the components and extensions you adopt. ### Is an agent harness the same as an SDK? A harness coordinates an agent's work. An SDK is a programming interface your application can use to control or embed that behavior. Claude Code and Claude Agent SDK, for example, serve different integration needs around related agent capabilities. ### Does an agent harness replace a sandbox? A harness coordinates tools and model requests; a sandbox constrains the environment executing code. Some products package them together. Check the actual execution boundary rather than assuming that tool approvals isolate a process. ### Can an AI agent harness run locally? Yes. A harness can run on your laptop, on a remote server, or in a managed cloud environment, depending on the product. Northflank Cloud Harness hosts coding agents in cloud workspaces that you access through the dashboard or SSH. Local execution of a harness does not necessarily mean its model runs locally. ### Can you run an agent harness in your own cloud? Yes, when the product supports that deployment model. A locally executable harness or SDK application can run on infrastructure you operate, while managed environments may offer bring your own cloud (BYOC). Check execution, storage, telemetry, and model-request destinations separately. ## Related articles about AI agent code execution Explore the infrastructure around your chosen harness: - [What infrastructure do AI agents need to run code safely?](https://northflank.com/blog/ai-agent-code-execution-infrastructure) covers the execution environment and its controls. - [What should an audit trail for AI-agent code execution contain?](https://northflank.com/blog/ai-agent-code-execution-audit-trail) explains the evidence needed to investigate a run. - [How to govern AI-agent code execution in enterprise environments](https://northflank.com/blog/govern-ai-agent-code-execution-enterprise) examines authority and operational policy. - [AI-agent sandbox security checklist](https://northflank.com/blog/ai-agent-sandbox-security-checklist) provides questions for reviewing execution boundaries. - [How to deploy an AI agent from sandbox to production](https://northflank.com/blog/how-to-deploy-ai-agent-from-sandbox-to-production) covers the next stage after experimentation.

How to optimise GPU utilisation and reduce cloud costs

2026-09-25T11:00:00.000Z

## TL;DR: how to optimise GPU utilisation and reduce cloud costs - GPU cost optimization starts with measuring utilisation, identifying idle capacity, and matching GPU types and quantities to workload requirements. - Scheduling, right-sizing, auto-shutdown, and shared GPU pools can increase utilisation and reduce wasted capacity. - Showback and chargeback make GPU costs visible across teams and help organisations control shared infrastructure spend. - [Northflank GPU workloads](https://northflank.com/product/gpu-paas) run on per-second billing with no minimum, autoscale by GPU utilisation metrics, and support BYOC into your own cloud account where reserved capacity and committed spend apply. > [Northflank](https://northflank.com/product/gpu-paas) provides GPU workloads on H100, H200, A100, L4, L40S, B200 and more with per-second billing, autoscaling, and bring your own cloud (BYOC). [Get started (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > GPU compute is expensive. An H100 at $2.74 per hour running at 15% SM utilisation costs the same as one running at 95%. The difference between those two numbers is not a pricing problem. It is a utilisation problem. Most organisations running GPU workloads are paying for more compute than their workloads actually use, and standard cloud cost reports often fail to show where that waste comes from. GPU cost optimization requires more than CPU right-sizing or autoscaling. Model loading, memory constraints, distributed training, and idle development environments create GPU-specific sources of waste. This guide covers how to measure GPU utilisation, identify wasted capacity, and improve GPU efficiency. ## Why GPU utilisation is harder to optimise than CPU CPU utilisation is a relatively direct measure of whether a workload is using the compute it was allocated. Low CPU utilisation on a running instance usually means the workload is idle, making it easier to identify capacity that can be downsized or shut down. GPU utilisation is more complex. GPU memory can determine whether a workload can run independently of compute utilisation, while large models can keep GPUs allocated during model loading or between requests. Distributed training adds another constraint because all GPUs required by a job may need to be available at the same time. These characteristics mean standard cloud cost reports can miss significant GPU waste, making GPU-specific monitoring and optimisation controls necessary. ## How to optimise GPU utilisation and reduce costs Improving GPU efficiency requires more than simply increasing utilisation. You need to understand what is consuming GPU capacity, match workloads to appropriate hardware, schedule workloads efficiently, and reclaim capacity when it is no longer needed. ### 1. Measure GPU utilisation correctly The metrics that matter for GPU cost optimization are not the same as the metrics cloud provider dashboards surface by default. **SM (streaming multiprocessor) utilisation** shows how much of the GPU's compute capacity is actively being used. **GPU memory utilisation** shows how much GPU memory is allocated, while **memory bandwidth utilisation** helps identify workloads that are limited by memory rather than compute. **Idle time** shows how long allocated GPUs are sitting without doing useful work. These metrics should be considered together. A GPU can have low SM utilisation while using most of its memory, such as when a model is loaded and waiting for requests. Looking at compute utilisation alone can therefore make an expensive GPU appear more efficient than it actually is. ### 2. Right-size GPU workloads Match the GPU type and quantity to the workload instead of defaulting to the most powerful hardware available. Measure GPU memory and compute requirements on representative workloads, then choose the smallest configuration that meets your performance requirements. Also separate baseline capacity from peak demand. Predictable workloads can use committed or reserved capacity, while interruptible workloads such as batch processing and checkpointed training can use more flexible capacity. Right-sizing the GPU and the number of GPUs can reduce costs before you make any changes to scheduling or autoscaling. ### 3. Schedule and place workloads efficiently How workloads are placed across your GPU infrastructure directly affects utilisation. **Bin-packing** can consolidate workloads onto fewer nodes, leaving unused nodes available for scale-down instead of spreading workloads across partially utilised nodes. For smaller workloads, **GPU partitioning or time-slicing** can allow multiple workloads to share a physical GPU. Distributed training introduces another challenge: jobs often need multiple GPUs to become available at the same time. Gang scheduling can prevent partially allocated jobs from holding GPUs idle while waiting for the rest of their capacity. ### 4. Detect and shut down idle capacity Idle GPUs are one of the clearest sources of wasted spend. Development environments, notebooks, completed jobs, and inference services can continue consuming GPU capacity long after useful work has stopped. Use idle-time monitoring, TTL policies, scheduled scale-down, and automatic shutdown to reclaim unused capacity. For production inference, scale GPU replicas based on actual demand while accounting for model loading time and latency requirements. This avoids keeping more GPU capacity running than the workload needs. ### 5. Use multi-tenancy and resource quotas Shared GPU pools can improve utilisation by allowing teams to use capacity when they need it instead of maintaining separate dedicated GPUs. Resource quotas prevent one team or project from consuming the entire pool. Use project or team-level quotas and workload priorities to balance development, training, and production workloads. For large training jobs, planned reservation windows can also help coordinate GPU capacity without allowing one workload to block the rest of the pool. ### 6. Use showback and chargeback for GPU cost allocation GPU cost allocation connects infrastructure spending to the teams using it. **Showback** makes GPU costs visible without directly charging them to team budgets, while **chargeback** allocates those costs to the responsible team or project. For either model, track GPU usage by team, project, workload, GPU type, and effective rate. Metrics such as cost per training run, cost per inference request, and idle GPU cost make the data actionable and help teams identify inefficient workloads. Together, these controls turn GPU cost optimization from a pricing exercise into an ongoing utilisation practice. Instead of simply buying cheaper GPUs, teams can reduce waste by ensuring the GPUs they already pay for are being used effectively. ## How Northflank handles GPU utilisation and cost optimisation [Northflank GPU workloads](https://northflank.com/product/gpu-paas) run on H100, H200, A100, L4, L40S, and B200 hardware with per-second billing and no minimum allocation. The billing model eliminates the idle cost of hourly minimums: a job that runs for 8 minutes bills for 8 minutes. - **Autoscaling:** GPU services on Northflank support [autoscaling](https://northflank.com/docs/v1/application/scale/autoscale-deployments) by CPU, memory, requests per second, or custom Prometheus metrics. For inference services, scaling based on request queue depth or P95 latency scales replicas in response to actual load rather than predicted load. Scale-to-zero can eliminate GPU compute billing during idle periods when the workload has a mechanism to detect new demand and restart capacity. - **Scheduled jobs:** [GPU jobs](https://northflank.com/docs/v1/application/gpu-workloads/gpus-on-northflank) on Northflank run to completion and release GPU allocation automatically. There is no ongoing cost after the job finishes. Scheduled training jobs, batch inference runs, and evaluation jobs run on their schedule and terminate, without holding GPU capacity between runs. - **Spot GPU orchestration:** [BYOC node pools](https://northflank.com/docs/v1/application/bring-your-own-cloud/deploy-and-scale-node-pools) on Northflank support spot instance configuration. Checkpointable training workloads can target spot GPU nodes at significantly reduced cost. Northflank orchestrates workload placement across available capacity and handles spot interruption by rescheduling on available nodes. - **BYOC for reserved capacity:** [Northflank BYOC](https://northflank.com/product/bring-your-own-cloud) deploys into your own cloud account, where GPU reserved instances, committed use discounts, and capacity reservations negotiated with your cloud provider apply directly to Northflank-managed workloads. Your existing GPU cost commitments reduce the effective rate Northflank workloads pay. - **Observability:** GPU utilisation metrics SM utilisation, memory utilisation, memory bandwidth are available through the Northflank observability layer alongside service logs, build metrics, and infrastructure events. [Log sinks](https://northflank.com/docs/v1/application/observe/configure-log-sinks) export to your existing observability stack for fleet-wide GPU cost dashboards. - [**RBAC and project isolation** ](https://northflank.com/docs/v1/application/secure/use-role-based-access-control): GPU workloads are scoped to projects, which maps to team boundaries for cost attribution. Project-level resource controls define which teams can launch GPU workloads and at what scale, providing the quota enforcement layer for multi-tenant GPU pools. [Request GPU capacity](https://northflank.com/request/gpu) for planned allocations. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ## Conclusion GPU cost optimization is primarily a utilisation problem, not a pricing problem. Measure utilisation, right-size workloads, schedule GPUs efficiently, eliminate idle capacity, and use quotas and cost allocation to make shared infrastructure more efficient. Northflank helps teams put these practices into place with flexible GPU workloads, autoscaling, per-second billing, and BYOC support. This makes it easier to match GPU capacity to workload demand, reclaim unused resources, and manage GPU infrastructure costs as your workloads grow. ## FAQ: how to optimise GPU utilisation and reduce cloud costs ### What is GPU utilisation? GPU utilisation measures how much of a GPU's compute capacity is actively being used by a workload. SM utilisation is the primary compute metric, but it does not tell the whole story. A GPU can have low SM utilisation while consuming most of its memory, such as when a model is loaded and waiting for requests. For accurate monitoring, consider SM utilisation alongside GPU memory utilisation, memory bandwidth, and idle time. ### What causes low GPU utilisation? Low GPU utilisation can come from several sources, including idle development environments, oversized GPU allocations, workloads waiting on data, inference services running below their expected traffic levels, and distributed training jobs waiting for enough GPUs to start. Each requires a different solution, such as auto-shutdown, right-sizing, better workload placement, autoscaling, or gang scheduling. ### What is GPU showback and chargeback? Showback makes GPU costs visible to each team without directly charging those costs to their budget. Chargeback goes further by allocating GPU costs to the team, project, or business unit responsible for the usage. Both approaches require accurate cost allocation data, such as GPU-hours, GPU type, workload, and effective rate. ### When should you use MIG partitioning vs time-slicing for GPU sharing? Use MIG when workloads need stronger isolation and predictable performance. MIG divides a supported GPU into isolated instances with dedicated memory and compute resources. Time-slicing allows multiple workloads to share a GPU without the same level of isolation and is better suited to development, experimentation, and workloads that can tolerate variable performance. ### How do you calculate GPU cost per training run? Multiply the number of GPUs used by the number of hours the workload ran and the effective GPU rate. For example, eight H100s running for 12 hours at $2.74 per hour would cost $263.04. For spot workloads, use the effective spot rate instead of the on-demand rate when calculating the actual cost. ## Related articles - [GPU autoscaling: how to scale without wasting capacity](https://northflank.com/blog/gpu-autoscaling) - [On-demand vs reserved GPUs for AI workloads](https://northflank.com/blog/on-demand-vs-reserved-gpus) - [Spot GPUs vs reserved GPUs](https://northflank.com/blog/spot-gpus-vs-reserved-gpus)

How to choose a bring your own cloud (BYOC) platform for your enterprise

2026-09-24T15:45:00.000Z

## TL;DR: how to choose a bring your own cloud platform - **Genuine BYOC means the workload data plane runs in your cloud account, user traffic enters your VPC directly, and infrastructure costs bill at standard rates with no markup.** Most platforms that use the term do not meet all three. - **Evaluate a BYOC platform across ten criteria:** data plane placement, control plane location, VPC networking, deployment requirements, upgrade model, team isolation, managed services, observability and audit logging, billing, and exit strategy. - [**Northflank BYOC**](https://northflank.com/product/bring-your-own-cloud) is self-serve on AWS, GCP, Azure, Oracle, CoreWeave, Civo, on-premises, and bare-metal. CI/CD, managed databases, preview environments, GPU workloads, and microVM sandbox isolation all run inside your own VPC. No enterprise sales process, no infrastructure markup, no annual commitment. > [Northflank](https://northflank.com/) provides self-service BYOC into AWS, GCP, Azure, Oracle, CoreWeave, Civo, on-premises, and bare-metal. Infrastructure costs are billed directly to your cloud account while Northflank handles cluster upgrades, scaling, and maintenance. [Get started (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > Most platforms that call themselves BYOC are not. Single-tenant SaaS in the vendor's data centre, private connectivity options layered on top of shared infrastructure, and dedicated instances that still run on the vendor's hardware all appear under the BYOC label. The gap between the marketing claim and what actually runs in your cloud account determines whether you get the data residency, cost control, and compliance outcomes you were evaluating BYOC to achieve in the first place. Choosing the wrong BYOC platform means discovering, after procurement and integration, that the vendor's load balancer sits in the request path, that infrastructure costs carry an undisclosed markup, that RBAC and SSO require an enterprise upgrade, or that migrating away requires re-architecting your deployment pipeline from scratch. This guide covers what genuine BYOC means and the criteria that separate platforms that deliver it from those that do not. ## What is a bring your own cloud platform? A bring your own cloud platform deploys its workload execution layer into your cloud account, rather than running your workloads on the vendor's infrastructure. Your applications, databases, and agent workloads run on cloud infrastructure you control, in a VPC you manage, with network traffic flowing into your infrastructure directly. The vendor manages the control plane, the software that orchestrates deployments, manages configuration, and provides the developer interface, but does not own the infrastructure your workloads run on. The distinction matters for three reasons. - **Data residency:** workloads that run in your cloud account stay within the network boundary you control, which is important for regulated industries and enterprise compliance requirements. - **Cost control:** genuine BYOC lets your workloads consume existing committed cloud spend, such as AWS, GCP, or Azure credits, rather than adding a new billing relationship. - **Audit and governance:** when compute runs in your cloud account, your cloud provider's audit trail covers infrastructure events, in addition to whatever the platform vendor provides. These benefits only hold when the data plane genuinely runs in your account. When the vendor's infrastructure sits between your users and your application, those benefits may not apply. ## How to evaluate a bring your own cloud platform Once you know what genuine BYOC means, the next step is evaluating how a platform actually works in your environment. Look beyond the BYOC label and examine where workloads run, how traffic flows, what the vendor manages, and what your team remains responsible for. The following ten criteria cover the areas that matter most when evaluating an enterprise BYOC platform, from data plane placement and networking to billing, governance, and your ability to leave the platform later. ### 1. Data plane placement: what actually runs in your cloud account The most important question is what the vendor actually deploys into your infrastructure. A genuine BYOC platform should deploy the workload execution layer, including the Kubernetes cluster, compute, databases, networking, and secrets management, into your cloud account. User traffic should enter your VPC directly rather than passing through the vendor's infrastructure. Before procurement, verify where requests enter the network, where TLS is terminated, what infrastructure the vendor controls, and whether the vendor can access application traffic. ### 2. Control plane placement and air-gap options In most BYOC deployments, the vendor operates the control plane on its own infrastructure and connects it to your data plane through a secure outbound connection. This works for most enterprise environments, but stricter environments may require the control plane to run entirely within your own perimeter. If your requirements include strict data isolation or air-gapped operation, check whether the platform supports a forward-deployed control plane and what happens to your deployments if the vendor's control plane becomes unavailable. ### 3. VPC networking: integration, egress, and private connectivity Your BYOC workloads still need to communicate with the services and systems they depend on. Evaluate whether the platform supports private connectivity to existing VPC resources, static egress IPs for allowlisting, connectivity across accounts, and private DNS. Also check whether the platform's networking model introduces an overlay or other constraints that prevent workloads from communicating directly with VPC-native resources. ### 4. Deployment requirements: what you provide, what the vendor provisions The setup process varies significantly between BYOC platforms. Some require an existing Kubernetes cluster and specific configurations, while others provision the infrastructure themselves from your cloud credentials. Look at what you need to provide, which IAM permissions are required, whether BYOC is self-serve, and how long it takes to get from connecting your cloud account to running workloads. ### 5. Upgrade model and operational responsibility BYOC does not automatically mean your team operates the underlying infrastructure. Establish exactly where responsibility sits for Kubernetes upgrades, node patching, security fixes, and platform updates. The more of these responsibilities the vendor handles, the less operational work your platform team needs to take on. Confirm the responsibilities and SLAs for the BYOC data plane before signing a contract. ### 6. Team isolation and multi-tenancy Enterprise BYOC deployments often serve multiple teams, business units, or compliance environments. Evaluate whether the platform provides sufficiently granular RBAC and isolation between teams and environments. Check whether access can be controlled at the organisation, project, environment, or resource level, whether SSO is supported, and whether directory sync can automatically revoke access when employees are offboarded. ### 7. Managed services alongside compute A compute-only BYOC platform can leave databases, queues, object storage, and other infrastructure managed separately. This creates additional operational and governance overhead. Evaluate whether the platform can provision managed services inside your BYOC environment and connect them to workloads through private networking. For AI workloads, also check whether GPUs can run inside the same environment. ### 8. Observability and audit logging Enterprise BYOC requires visibility into both platform events and application activity. Your team should be able to access deployment and configuration events alongside application logs, metrics, and health signals. Check whether audit logs cover the BYOC data plane, whether they can be exported to your SIEM, how long they can be retained, and what telemetry the vendor collects from your environment. ### 9. Billing model and infrastructure cost ownership BYOC costs have two components: the platform fee and the infrastructure costs paid to your cloud provider. Make sure you understand how both are calculated. Infrastructure should bill directly to your cloud account, and you should know whether the platform adds a markup. Also compare seat-based and usage-based pricing, check whether workloads can consume existing cloud commitments, and look for minimum spend requirements. ### 10. Exit strategy and vendor dependency BYOC reduces some forms of infrastructure lock-in, but it does not eliminate vendor dependency. If deployment pipelines, secrets, databases, and infrastructure are tightly coupled to proprietary abstractions, leaving can still require significant rework. Before choosing a platform, check whether your configurations use portable standards, whether secrets can be exported, whether the underlying Kubernetes cluster continues to operate after termination, and whether the vendor provides a documented migration path. ## How Northflank meets these criteria [Northflank BYOC](https://northflank.com/product/bring-your-own-cloud) deploys the workload data plane into your cloud account, with user traffic entering your VPC directly. Northflank manages the platform through its control plane without sitting in the request path or storing application data. - **Data plane:** CI/CD, managed databases, preview environments, GPU workloads, and microVM sandbox isolation run inside your VPC. Northflank provisions and manages the Kubernetes cluster, while compute and infrastructure costs remain in your cloud account with no markup. - **Control plane:** The standard BYOC model uses Northflank's managed control plane with a secure outbound connection to your data plane. For regulated and air-gapped environments, the [forward-deployed control plane](https://northflank.com/enterprise) runs the platform, API, and audit database within your environment. - **Self-serve setup:** BYOC is available on all plans, including the free tier. Connect your cloud account and deploy your infrastructure without an enterprise sales process, professional services engagement, or annual commitment. - **Cloud coverage:** Northflank supports AWS, GCP, Azure, Oracle, CoreWeave, Civo, Nebius, on-premises Kubernetes, and bare-metal. [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok) also lets you connect eligible existing Kubernetes clusters. - **Networking:** BYOC supports [private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank), [static egress IPs](https://northflank.com/docs/v1/application/bring-your-own-cloud/configure-static-egress-ips), and [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies) for controlling traffic between workloads and environments. - **Team isolation and governance:** [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control) is available at the organisation, team, project, and resource levels. [SAML and OIDC SSO](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication), directory sync, and automatic deprovisioning support enterprise identity and access requirements. - **Observability and audit logging:** [Audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) provide organisation-to-resource visibility and can be exported to SIEM systems. [Log sinks](https://northflank.com/docs/v1/application/observe/configure-log-sinks) can send logs to external observability providers, Amazon S3, or HTTP endpoints. Northflank is SOC 2 Type 2 certified, with HIPAA BAA availability under Enterprise agreements. - **Billing:** Infrastructure costs bill directly to your cloud account at standard rates with no markup. The Northflank platform fee is usage-based rather than seat-based, and BYOC workloads can consume existing committed cloud spend agreements. - **Exit strategy:** Northflank deploys standard Kubernetes into your account. If you stop using Northflank, your cluster and workloads remain in your infrastructure, giving you a path to continue operating them independently. [Secret groups](https://northflank.com/docs/v1/application/secure/manage-secret-groups) also integrate with standard secrets management workflows. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your BYOC requirements. ## FAQ: how to choose a bring-your-own-cloud platform ### What is a bring-your-own-cloud platform? A BYOC platform runs your workloads in your cloud account while the vendor manages the platform that deploys and operates them. ### How does BYOC compare with self-hosting? Self-hosting means your team operates the infrastructure and platform yourself. BYOC keeps the infrastructure in your account while the vendor handles platform operations such as upgrades and maintenance. ### Does BYOC satisfy HIPAA and data residency requirements? BYOC can support HIPAA and data residency requirements when combined with the required controls, such as appropriate cloud regions, encryption, access controls, audit logging, and a Business Associate Agreement where required. ### What is the difference between BYOC and BYOK? BYOC lets a platform provision and manage infrastructure in your cloud account. BYOK connects the platform to a Kubernetes cluster you already operate. ### What should I check before signing a BYOC enterprise contract? Check where workloads and traffic run, who owns infrastructure costs, what security and access controls are included, what your team is responsible for, and how easily you can leave the platform. ## Related articles - [What is BYOC in cloud computing?](https://northflank.com/blog/what-is-byoc-in-cloud-computing) - [Best options for BYOC in cloud computing](https://northflank.com/blog/best-options-for-byoc-in-cloud-computing) - [BYOC vs self-hosting vs managed cloud](https://northflank.com/blog/byoc-vs-self-hosting-vs-managed-cloud)

August & September 2026 | Changelog

2026-09-24T08:30:00.000Z

August and September brought a major new way to work with Northflank: Harnesses, which let you run coding agents against your repositories in managed workspaces with browser terminals, SSH, and persistent storage. We also expanded our AI, sandboxing, and BYOC capabilities with self-service microVMs on BYOC and AWS launch template support. Across the platform, we added organization-wide security policies and access controls, customer-managed envelope encryption, and new BYOC capabilities. We also introduced container snapshots, scheduled volume backups, per-replica volumes, and private VPC load balancers. Template version history and run diffs, richer addon metrics, and a new Delhi region round out the updates. ### Harnesses Coding agents can now work directly inside a managed Northflank workspace. Choose Claude Code, OpenAI Codex, Cursor, OpenCode or Pi, authenticate with your own account or API key, and connect through the browser terminal or SSH. Harnesses include persistent workspace volumes, custom runtime images, GPUs and networking, and can be created from the dashboard, public API, or as a template node. Teams can also set harness policies and make harnesses private. Harnesses are billed like other runtime resources. ![claude-code-create.png](https://assets.northflank.com/claude_code_create_eb75a1e0aa.png) ### Self-service microVMs on BYOC You can now install sandbox security on your own clusters and run workloads with microVM or gVisor isolation inside your own cloud. This is designed for untrusted code, coding agents, and multi-tenant workloads that need a stronger isolation boundary, while keeping compute and data in your own infrastructure. Services, jobs, addons, and builds can each use their own sandboxing mode, with support for Kata microVMs, gVisor or no sandboxing. AWS instances with nested virtualization can also be used for microVM workloads. ![Screenshot 2026-09-24 at 09.59.42.png](https://assets.northflank.com/Screenshot_2026_09_24_at_09_59_42_cf6d3bf7c5.png) ### AWS launch templates BYOC node pools on AWS can now use your own EC2 launch templates, so nodes can be provisioned with your own AMI, user data, storage, and network configuration instead of Northflank's defaults. Launch templates can also be used to enable nested virtualization on EKS nodes, allowing supported instance types to run microVM workloads. ### Envelope encryption with your own keys You can now use your own cloud KMS key to wrap encryption keys, or opt into Northflank-managed envelope encryption. This lets you retain control over your secrets even when they are stored on the Northflank control plane. Encryption configuration can be managed through the API, and default encryption keys can be rotated. ### Organization security policies and access controls Organization administrators can now define ingress security policies that apply across teams. Policies can be organised into required and optional controls, giving organizations more control over the security requirements applied across their teams. Organizations can also require SSO for managed accounts, stop teams from creating their own clusters, and prevent addons from being made publicly accessible. ### Improved invitations Team and organization invitations have been redesigned. The invite page shows which account you're signed in as and anything stopping you from joining, fills in the invited email address, and takes you straight to the team or organization once you accept. Pending invitations are shown in the dashboard header. ### AWS EU Sovereign Control Plane Northflank now supports the AWS EU Sovereign Control Plane for BYOC clusters, extending BYOC deployments to AWS's European sovereign infrastructure. ECR registries, Route 53 DNS, OpenTofu, workload identity and launch templates all work within the sovereign partition. ### Nebius support Nebius is now available as a bring your own cloud provider. Create and manage Nebius clusters from Northflank, including GPU node pools, with networking and subnet configuration handled through the standard cluster creation flow. ### BYOC cluster improvements AWS BYOC clusters can now use Kata microVM sandboxing through nested virtualization and can be converted from the default VPC to a custom VPC. Oracle OKE clusters and node pools can also be upgraded to newer Kubernetes versions. Cluster autoscaler events now appear alongside your other cluster events, and AWS clusters have a direct link to the autoscaler logs. Azure cluster creation picks a default vNet mode and suggested node types for you, and the integrations list now shows which BYOC features each integration supports. ### Cursor Origin as a Git provider Connect Cursor Origin to Northflank and use it to build and deploy your repositories. Repository sync, pull requests, build checks, and webhooks are supported. ### New Delhi region Asia South (Delhi) is now available as a public Northflank Cloud region. ### More GPUs On-demand NVIDIA L4 GPUs are now available in the Netherlands region, NVIDIA H100s in Frankfurt, and NVIDIA RTX PRO GPUs in US West. ### Private VPC load balancers Private load balancers can now be created inside your VPC, allowing services to remain accessible only from your private network. Private AWS load balancers support security groups, and BYOK clusters can configure public and private ingress load balancers separately. ### Load balancer network policies Network policies can now control ingress traffic to load balancers. ### Tailnet services Northflank can now automatically create Tailscale VIP services for resources in a project, exposing their TCP and HTTP ports on your tailnet. You can optionally restrict the resources using tags. ### CDN caching presets and purging Northflank CDN now includes caching presets for common workloads, including safe mode and static assets. You can also purge a subdomain's CDN cache from the dashboard, CLI, or API. ### Domain and TLS controls You can now configure a minimum TLS version and TLS mode for wildcard domains on shared gateways, and renew certificates before they expire. ### Container snapshots You can now capture the filesystem of a running or terminating service pod and restore a service from a successful snapshot. Snapshots are available through the dashboard, CLI, and API and require a Kata runtime. ### Scheduled volume backups Platform volumes can now be backed up on a schedule from the dashboard, with failure alerting built in. Backups can also be restored after the source volume has been deleted. ### Backup improvements Backup destinations now support S3 Object Lock and workload identity authentication. Forks can use the latest available backup without specifying one, while PostgreSQL dumps now run against a read replica instead of the primary. ### Per-replica volumes Stateful set services can now use persistent volumes that follow each replica. These volumes are managed alongside your other project volumes, making it easier to give each replica its own persistent storage. ### Addon metrics and status Addons now have a metrics summary with storage warnings, and HA addons show which replica is the primary. Bucket addons now show metrics too. New MongoDB, Redis and RabbitMQ versions are available. ### Rebuilt billing dashboard Billing has a new layout with separate Overview, Usage, and Invoices tabs. You can drill into spend over time, see itemised cloud runtime costs on invoices, and track egress IP and load balancer usage in metered billing. UK customers with a verified tax ID can now see VAT in GBP on invoice PDFs. Payment-method prompts are now clearer for both free and paid plans, and you can add a card while creating a team. ### Template version history and run diffs Templates now keep a history of previous versions, with a detail view and the ability to revert to an earlier revision. Each template run also records a per-node diff so you can see what changed during the run. ### Template node update modes Supported template nodes can now specify how their target resource should be handled: create, update, or patch. ### Global secret template triggers Templates can now be triggered automatically when a global secret is updated, making it easier to keep dependent resources in sync. ### Template shareable links Shareable template links can now be limited to your organization, and they expire after a year of inactivity. ### Build services from source bundles Build services can now build directly from a bundle URL instead of a Git repository. Bundle builds can also be started from the dashboard with an optional branch and commit SHA. ### Build improvements BuildKit's local disk cache is now generally available. Builds can also be skipped when a commit contains no changes. ### Job run overrides Job runs can now override GPU settings along with plan and storage. Eligible jobs and cron jobs can also run without init containers. ### Secret group restrictions Secret groups can now be restricted to specific environments as well as tags. Teams can also define a default restriction mode for newly created secret groups. ### Addon secret rotation Addon credentials can now be rotated without immediately invalidating the previous credentials. The old credentials remain valid until rotation is finalised, with support for PostgreSQL HA and MongoDB. ### Redis ACL support Redis addons can now persist and synchronise ACLs across primaries, replicas and sentinels. A Northflank-managed superuser keeps platform operations working even when access for the default user is restricted. ### API and CLI improvements API tokens can now be listed, rotated and deleted, while Git accounts can be linked directly from the CLI. Teams can also be deleted through the API, and a new authentication endpoint returns details about the credentials used for a request. Billable resource responses now include a UID. ### Sentry log sink Workload logs can now be forwarded to Sentry through the existing log sink configuration. ### Convert teams into organizations Teams can now be converted into organizations directly from team settings through a resumable migration flow. ### Redesigned documentation We’ve redesigned the Northflank documentation with a new look and improved navigation, making it easier to find and work through the information you need. ### New stack templates We added Bucardo and GitLab stack templates, along with a Qwen3 template configured for speculative decoding. ### Region selection improvements Project creation now separates recommended regions from the full list and shows region counts. Regions also display their provider city where available. ### Plus many smaller fixes and refinements We improved sign-in and SSO, API token filtering, preview blueprint pagination, project editing, deployment restart information, command menu coverage (now including workflows and preview blueprints), metrics charts (now with annotations), and Observe navigation. Resources can now be duplicated into another project. Pod lists now load more reliably, build and job timings have been corrected, add-on Slack alerts are quieter, and several rate-limit, crash, and type-error issues have been fixed across the platform.

Control plane vs data plane in BYOC: What runs where?

2026-09-23T15:46:00.000Z

Control plane vs data plane in Bring Your Own Cloud (BYOC) is a separation of responsibilities: the control plane manages deployments and configuration, while the data plane runs applications and processes workload data. In a common BYOC architecture, the vendor hosts the control plane and your cloud account hosts the data plane. Some deployments place both planes in your environment. For your enterprise, evaluating BYOC means understanding both where components run and who operates them. This guide explains that boundary, which data can leave your account, and what to check about access, upgrades, and control-plane outages. ## TL;DR: Control plane vs data plane in BYOC In a common BYOC architecture, the vendor hosts the application platform's control plane, while the data plane runs in your cloud account. - **The control plane manages resources.** It handles deployment configuration and management operations. The data plane executes application code and processes workload data. - **Location and management are separate.** Your enterprise can own the cloud account while the vendor operates the platform and manages the workload infrastructure. - **Data placement needs a category-by-category check.** Workload data, metadata, logs, build artifacts, secrets, and backups may have different storage and access arrangements. - **Check dependencies before assuming independence.** Confirm what continues during a management outage and whether your requirements also call for a control plane inside your environment. If your team needs to deploy workloads in your own cloud account, [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud) provisions and manages Kubernetes clusters in your AWS, Google Cloud, Microsoft Azure, Oracle Cloud, CoreWeave, Civo, or Nebius account. Your workloads run on that infrastructure while Northflank handles cluster upgrades, scaling, and maintenance. [Get started self-serve](https://app.northflank.com/signup), or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your enterprise’s architecture, data boundaries, and operational responsibilities. ## What is the difference between the control plane and data plane in BYOC? The control plane configures and manages the system; the data plane performs the work the application exists to do. For an application platform, changing a deployment's configuration is a control-plane operation. An application receiving a request, querying a database, and returning a response performs data-plane work. The following comparison describes a common BYOC split. Individual products can place components differently. | Dimension | Control plane | Data plane | | --- | --- | --- | | Main role | Configure and manage deployments | Execute workloads and process application data | | Typical components | Management API, dashboard backend, configuration store, deployment automation | Application services, workers, databases, storage, traffic-serving components | | Common BYOC location | Vendor-hosted environment | Your own cloud account and network | | Example operation | Change an application's image or requested capacity | Handle an API request or process a queued job | | Operational responsibility | Vendor usually operates hosted platform management | Vendor and customer responsibilities depend on the deployment agreement | Both planes contribute to the same service. Compare their roles and dependencies rather than choosing between them. ## Where do the control plane and data plane run in BYOC? In a common BYOC deployment, the data plane runs in your cloud account and VPC, while the application platform control plane runs in the vendor’s environment. A forward-deployed arrangement can place the platform control plane in your environment as well. Your environment may contain worker nodes, application containers, databases, persistent volumes, and ingress components. It can also contain vendor-installed agents, controllers, and monitoring components. A hosted control plane therefore does not mean every piece of management software runs outside your account. The management path connects your deployment tools to the platform and its cluster integration. The application path connects your users or internal services to the running workload and its data stores. Keeping these paths separate helps your team identify which connections are required to deploy software and which are required to serve requests. If your team needs to run services, jobs, and databases in your own cloud account, Northflank’s [BYOC cloud integrations](https://northflank.com/docs/v1/application/bring-your-own-cloud/use-other-cloud-providers-with-northflank) support AWS, Google Cloud, Microsoft Azure, Oracle Cloud, CoreWeave, Civo, and Nebius. Northflank provisions and manages the Kubernetes clusters, while your cloud provider bills you directly for the underlying infrastructure. ### Is the Kubernetes control plane the same as the platform control plane? The Kubernetes control plane and the application platform control plane are different layers. Kubernetes manages cluster state and schedules workloads; the platform control plane manages the developer-facing deployment workflow across its connected infrastructure. Kubernetes includes an API server, scheduler, controllers, and a state store. Worker nodes run the containers. These are separate components, even when a platform presents them through one interface. With managed Kubernetes, the cloud provider may operate the cluster control plane. For your deployment, identify who operates each control plane and who manages cluster upgrades. With [Northflank Bring Your Own Cloud (BYOC)](https://northflank.com/features/bring-your-own-cloud), Northflank provisions and manages the Kubernetes cluster in your cloud account. With [Bring Your Own Kubernetes (BYOK)](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok), you connect an eligible existing cluster that your team provisions and operates. Your team remains responsible for Kubernetes upgrades, node scaling, and underlying infrastructure maintenance, while Northflank manages workload orchestration and its installed platform components. ## How do the control plane and data plane communicate in BYOC? A BYOC control plane communicates with the workload environment through a management integration, such as a cluster API or a local agent. That connection carries deployment instructions and operational status. Application requests can follow a separate path directly to the data plane. Consider an internal API connected to a private database in your cloud. A simplified release follows this sequence: 1. A developer or CI workflow requests a new application version through the platform's management interface. 2. The platform checks the request's permissions and applies the deployment configuration through its cluster integration. 3. The cluster starts the application containers using the selected image and runtime configuration. 4. Application clients reach the API through its configured endpoint; the API queries the database and returns responses. The management request and the application request follow different paths. The platform can manage an API without relaying every request to that API through its central management service. For your application, trace ingress, authentication, storage, and outbound calls separately. Those paths determine which services must be reachable for a request to succeed. ## Does BYOC keep all data in your cloud account? BYOC does not automatically keep every data category in your cloud account. Workload data can remain local while control-plane metadata, logs, metrics, build images, or backups are stored elsewhere. Check each category’s destination and configuration separately. Start with the application payload, then inspect the information generated while building, deploying, monitoring, and supporting it. A request body written into an error log remains sensitive even if the logging system classifies it as telemetry. Likewise, a resource name or configuration value should be assessed by its contents, rather than assumed harmless because it is metadata. With standard Northflank BYOC, workloads run in your cloud account and Northflank hosts the platform control plane. Other [data storage locations](https://northflank.com/security) depend on the category and configuration: | Data category | Northflank BYOC placement | | --- | --- | | Workload runtime and workload data | Your BYOC environment | | Control-plane metadata | Northflank-hosted | | Logs and metrics | Northflank-hosted or BYOC; logging defaults to Northflank-hosted | | Build execution | Your cluster by default, with other build-infrastructure choices | | Build images | Northflank-hosted by default, with a custom-registry option | | Disk snapshots | Your BYOC environment; global copies can use a configured S3-compatible destination | | Database dumps | Northflank-hosted storage for standard dump backups; native global backups can use a configured custom S3-compatible destination | If your build process must stay within an approved environment, Northflank lets you [select build infrastructure](https://northflank.com/docs/v1/application/bring-your-own-cloud/configure-your-cluster): the deployment cluster, a separate build cluster, or Northflank's build infrastructure. Build execution and image storage are separate choices. If your project’s build images must remain in your cloud account, Northflank supports a [custom build registry](https://northflank.com/docs/v1/application/build/use-custom-build-registry). Select it when creating the project; that selection cannot be changed on an existing project. For backup residency, configure an appropriate [global backup destination](https://northflank.com/docs/v1/application/databases-and-persistence/global-backup). Map secrets separately: where they are stored, who can retrieve them, how workloads receive them, and whether support or deployment credentials provide another access path. Encryption, storage location, and administrative authority answer different questions. ## Who manages the control plane, Kubernetes, and workloads in BYOC? In a typical managed BYOC arrangement, the vendor operates the hosted platform control plane, your enterprise owns the cloud account, and your team owns the application. Kubernetes lifecycle, infrastructure maintenance, and recovery responsibilities depend on the product and service agreement. For each layer, identify an operator and an escalation owner. Your cloud team may govern the account, permissions, network boundaries, and billing. The platform vendor may provision clusters and maintain platform components. Your application team still needs ownership of application behavior, release decisions, and data-recovery requirements. Write down who responds when a node fails, a database needs restoring, an upgrade affects an application, or a management credential is revoked. “Vendor-managed” is too broad to assign every incident automatically. If your team already operates Kubernetes, Northflank provides [Bring Your Own Kubernetes (BYOK)](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok). Your team retains cluster provisioning, version upgrades, node management, and underlying networking and storage components; Northflank manages its installed platform components and workload orchestration. Imported clusters must meet the requirements, and Northflank recommends a new, dedicated cluster for import. Northflank provisions and manages the cluster with BYOC. If your team is still deciding how much operational responsibility to take on, compare [BYOC, self-hosting, and managed cloud](https://northflank.com/blog/byoc-vs-self-hosting-vs-managed-cloud). ## What happens to the BYOC data plane if the control plane goes down? The BYOC data plane can continue serving existing workloads during a control-plane outage only if the required runtime dependencies remain available. Deployments, scaling, credential renewal, or recovery may still be affected. The behavior depends on the architecture and must be tested. Running workloads in your own account does not prove that they can operate without the vendor’s management services. Ask which operations require an active management connection and test the consequences of losing it. Evaluate at least four scenarios: - **Serving traffic:** Can existing application instances accept requests without a management API call? - **Changing deployments:** Can you release, roll back, or change configuration during the outage? - **Replacing capacity:** Can the system replace failed instances or add nodes, and which control plane does that require? - **Renewing dependencies:** What happens when credentials expire, an image must be pulled, or a restore is needed? An application can continue serving at its current capacity and still lose its ability to recover from a second failure. Test the specific management disconnection you expect, then record which operations continue, which stop, and how service is restored. ## When do you need a forward-deployed control plane? A forward-deployed control plane runs inside your environment. It becomes relevant when your enterprise prohibits externally hosted management, requires management data to remain inside its boundary, or needs disconnected operation. Moving application compute into your VPC addresses only part of that requirement. Review management connectivity, identity dependencies, update delivery, observability, and support access before deciding whether a deployment can operate within the required boundary. If your enterprise needs that arrangement, [Northflank for Enterprise](https://northflank.com/enterprise) supports a forward-deployed control plane in your VPC or data center, including zero-egress and air-gapped configurations. Standard BYOK still requires connectivity to Northflank's control plane; importing a cluster does not create an air-gapped deployment. Agree who operates, upgrades, backs up, and recovers the local management services. Placement alone does not make the platform self-hosted. If local management is a requirement, compare [platforms that support forward-deployed control planes](https://northflank.com/blog/platforms-forward-deployed-control-planes). ## Where do Northflank’s control plane and BYOC workloads run? In standard [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud), Northflank hosts the platform control plane while workloads run in your own cloud account. Northflank provisions and manages the Kubernetes cluster, including upgrades, scaling, and maintenance. [Enterprise forward deployment](https://northflank.com/enterprise) can also place the platform control plane in your environment. For self-serve BYOC, [connect your cloud account](https://northflank.com/docs/v1/application/bring-your-own-cloud/use-other-cloud-providers-with-northflank) and configure the cluster where workloads will run. Your cloud provider bills the infrastructure separately from Northflank's platform charges. Start with the [BYOC and BYOK requirements](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements), then select the deployment boundary that matches your team: a Northflank-managed BYOC cluster, an eligible cluster your team operates, or an Enterprise forward-deployed control plane. Decide data-location settings before creating projects and approving the architecture. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## Frequently asked questions about control planes and data planes in BYOC These distinctions help when reviewing a vendor's architecture. ### Is the data plane just a database? The data plane includes application execution, traffic processing, and relevant storage. It is broader than a database: APIs, background workers, and inference services also perform data-plane work. ### Does a hosted control plane receive every application request? A hosted control plane does not necessarily receive application traffic. Requests can go directly to the workload environment, depending on the architecture. Inspect gateways, proxies, and authentication dependencies to establish the actual path. ### Is BYOC the same as self-hosting? BYOC and self-hosting assign operational responsibility differently. BYOC can combine your infrastructure ownership with vendor-managed operations; self-hosting makes your team responsible for operating the software. Physical location alone does not determine the model. ### Does a local data plane remove vendor dependency? A local data plane does not remove every vendor dependency. Management, releases, credentials, support, or recovery may still depend on the vendor. Evaluate continued operation and your ability to migrate separately. ## Related articles about BYOC architecture Continue with the deployment and management decisions behind the architecture: - [BYOC vs self-hosting vs managed cloud](https://northflank.com/blog/byoc-vs-self-hosting-vs-managed-cloud) - [Which platforms support forward-deployed control planes?](https://northflank.com/blog/platforms-forward-deployed-control-planes) - [Is BYOC the future of software deployment?](https://northflank.com/blog/is-byoc-the-future-of-software-deployment) - [How to manage workloads across cloud, customer VPCs, and on-premises environments](https://northflank.com/blog/how-to-manage-workloads-across-cloud-customer-vpcs-and-on-premises-environments)

GPU autoscaling: How to scale without wasting capacity

2026-09-23T15:45:00.000Z

GPU autoscaling reduces wasted capacity when you scale application replicas using workload demand, coordinate GPU node capacity with those replicas, and release idle infrastructure while meeting your latency or job-completion targets. Reducing replica count alone can leave GPU nodes running and your team paying for unused capacity. This guide explains how to choose scaling metrics, account for model startup, configure scale-down, and measure the results, using inference services as the main example. ## TL;DR: GPU autoscaling without wasting capacity GPU autoscaling should match ready replicas and GPU nodes to workload demand, then release idle capacity as demand falls while maintaining your performance targets. - Measure one replica against your latency or job-completion target before choosing thresholds. - Use workload signals such as queue depth and active requests, with GPU metrics for context. - Coordinate application replicas with GPU node capacity and placement requirements. - Allow for model startup and stable scale-down without interrupting work unnecessarily. - Track successful work, service quality, and paid capacity together. To scale GPU services on managed Northflank Cloud or in your own cloud account, [Northflank GPU workloads](https://northflank.com/product/gpu-paas) support [custom-metric autoscaling](https://northflank.com/docs/v1/application/scale/autoscale-deployments) to match service capacity to demand. If you deploy in your own cloud, configurable [BYOC node pools](https://northflank.com/docs/v1/application/bring-your-own-cloud/deploy-and-scale-node-pools) also let you scale the underlying infrastructure within your chosen limits. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss GPU workload architecture and capacity. ## What is GPU autoscaling? GPU autoscaling is the automatic adjustment of application replicas or GPU infrastructure to match workload demand. It adds capacity as demand increases and removes capacity as demand falls, within configured limits. An application replica is one instance of your service. A GPU is a device that replica uses. A node is the machine supplying GPUs, CPU, memory, and storage. One replica may need several GPUs, and one node may hold several replicas. In Kubernetes, the workload autoscaler changes replica count, while a node autoscaler supplies or removes machines. Adding replicas only helps when they can be scheduled and become ready. Removing them releases their allocation, but the node may remain in place. ## Why can GPU capacity go unused even with autoscaling? GPU capacity can remain unused when replica counts fall but nodes stay allocated, minimum capacity exceeds demand, or free GPUs cannot satisfy a workload's placement requirements. Application scaling and infrastructure scaling need to work together to release that capacity. Use these symptoms to guide diagnosis: | Symptom | Possible cause | What to check | | --- | --- | --- | | Replicas sit idle between bursts | Minimum capacity exceeds the workload's needs | Warm-capacity requirement and scale-down policy | | Replica count falls but nodes remain | Pool minimums or other workloads retain nodes | Node occupancy and removal rules | | Replicas wait despite free GPUs elsewhere | Available devices do not fit placement or resource requirements | GPU count, node shape, and scheduling constraints | | GPU activity is high but useful throughput is poor | The utilization signal does not explain application performance | Request mix, batching, and latency | The [Kubernetes autoscaling guide](https://northflank.com/blog/the-complete-guide-to-kubernetes-autoscaling) explains the general controllers. For GPU workloads, check the full path from requested replicas to usable devices and ready application capacity. ## Which metrics should drive GPU autoscaling? GPU inference autoscaling should use queue depth, active requests, or batch size as workload signals, with latency checks to validate performance and GPU utilization and memory metrics to diagnose resource pressure. Choose and test thresholds against your service's response-time target. For inference, queue depth shows requests waiting for service. Active requests or batch size show work already being processed. Queue-based scaling can suit throughput goals, while tighter latency requirements may justify responding earlier to active work. Track response latency or time to first token to judge whether the policy works. GPU utilization provides context, but a busy device does not reveal how much additional inference it can handle. Allocated GPU memory also needs care: servers that preallocate memory may retain it after traffic falls. A memory threshold can therefore prevent useful scale-down. Define each metric precisely. A queue inside one replica differs from a shared backlog used by every worker. Before setting a target, establish whether the scaler receives a total, an average, or a per-replica value. If your application needs its own scaling signal, Northflank supports [custom Prometheus metrics](https://northflank.com/docs/v1/application/scale/autoscale-deployments). Gauge values are averaged across running pods; counters use a rate before averaging. If every pod exposes the same shared queue total, averaging returns that same total, not the backlog per replica. Northflank uses the resulting value and the current replica count to calculate the desired instance count. Design the metric and threshold together so that adding workers changes the signal as intended. ## How do you configure GPU autoscaling around real capacity? Configure GPU autoscaling by measuring one replica's sustainable throughput, setting replica limits and workload-metric thresholds, and matching GPU node capacity to those limits. Account for model startup and graceful scale-down before testing the complete demand cycle. Repeat this process when the model, hardware, or request mix changes. ### 1. Measure one ready replica Test one warmed replica with representative requests and a defined response-time target. Record the model version, GPU configuration, input and output sizes, and batching settings. Increase load gradually while observing successful throughput, waiting requests, and latency. Identify the load the replica can sustain while meeting your target. Save the test configuration alongside the throughput measurement. A requests-per-second figure is only useful when the requests resemble those your service will receive. Retest with longer requests and bursts before using the result to size production capacity. ### 2. Set replica limits and scaling thresholds Choose a minimum that meets your availability and startup requirements, then a maximum your infrastructure can accommodate. Set the scale-up threshold early enough for new replicas to start. Check for repeated additions and removals, and adjust stabilization accordingly. Treat the maximum as a capacity limit. It does not determine the full bill: how long replicas run, the nodes retained underneath them, and other infrastructure still affect cost. Decide what acceptable service behavior looks like when demand exceeds that limit, and include that condition in testing. ### 3. Make GPU nodes available to those replicas Ensure the node configuration can satisfy each replica's complete resource request. Check GPU type and count, CPU, RAM, storage, and placement constraints. Free GPUs spread across nodes may not satisfy a replica that needs several devices together. Check provider quotas and available capacity before relying on a higher replica maximum. If workloads must run in your own cloud, Northflank provides [BYOC node-pool autoscaling](https://northflank.com/docs/v1/application/bring-your-own-cloud/deploy-and-scale-node-pools) with minimum and maximum node counts and scheduling controls. Align those bounds with the service's requirements so replica growth has somewhere to run. If you need a specific GPU type and quantity for a planned workload, [request GPU capacity from Northflank](https://northflank.com/request/gpu) to discuss your requirements and timeframe. The guide to [running CPU and GPU workloads in your own VPC](https://northflank.com/blog/platforms-cpu-gpu-workloads-own-vpc) covers the wider infrastructure choice. ### 4. Include startup and model loading in capacity planning Count a new replica as serving capacity only after the application is ready to accept work. Measure the interval between requesting capacity and serving a successful request. Separate scheduling delays from container initialization and model loading. Otherwise, increasing the replica count can make a dashboard look healthy while the original instances still carry all the traffic. If repeated model downloads slow restarts, Northflank supports [persistent model storage](https://northflank.com/docs/v1/application/gpu-workloads/configure-and-optimise-workloads-for-gpus). Retaining files can reduce repeated downloads, but the application must still initialize and load its model. Check the storage arrangement against your intended replica placement. Provision enough CPU, memory, and temporary storage for startup as well as steady operation. An available GPU is not enough if the application runs out of memory or temporary storage while starting. ### 5. Test scale-down as carefully as scale-up Reduce capacity only after checking both sustained demand and the work still running. Use stabilization to avoid removing capacity during a brief dip. Then test application shutdown: stop taking new work and allow active requests to finish within the configured termination period. [Kubernetes graceful termination](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#termination-of-pods) has a deadline; remaining processes can be killed when it expires. A long-running request therefore needs explicit shutdown handling. Include interrupted requests and retries in your test results rather than counting every removed replica as a successful optimization. After demand falls and replicas shut down, check whether their nodes can also be removed. Find out why idle nodes remain before making scale-down more aggressive. ## When should GPU workloads scale to zero? GPU workloads should scale to zero when idle periods justify releasing the last replica, requests can tolerate cold-start delays, and an external mechanism can detect new demand and restart capacity. Intermittent work with flexible completion times is a better candidate than an interactive endpoint with a strict first-response target. Compare the expected idle interval with measured startup behavior before choosing between zero replicas and a warm minimum. Before enabling scale-to-zero on Northflank or another platform, confirm that the platform or an external controller can detect demand and restart the service from zero. Enabling metric-based autoscaling alone is not enough to assume that recovery will happen. Decide where requests wait, how long they can wait, and what callers receive if startup fails or takes too long. Test the recovery path with no replicas running: send new work, check that a replica starts and serves it, then check that idle GPU nodes are released when demand ends. ## What does a GPU scaling cycle look like in practice? A GPU scaling cycle detects increased demand, adds replicas and any required nodes, waits for the application to become ready, and removes excess capacity after demand falls. Use your load-test results to estimate how many ready replicas can handle the expected traffic within your latency target. Allow additional capacity for bursts and failures, and account for waiting requests and the time new replicas need to start. Follow the scaling cycle through four steps: 1. **Demand rises.** The measured workload signal crosses its target and the scaler requests more replicas. 2. **Capacity starts.** Replicas wait for suitable nodes if necessary, then initialize. They do not yet contribute their measured throughput. 3. **Replicas become ready.** Check that waiting work declines and response times meet the target. 4. **Demand falls.** After stabilization and graceful shutdown, check whether freed nodes leave the allocated fleet. If the final step retains the same machines, you have reduced application allocation without necessarily reducing infrastructure spend. ## How do you check that GPU autoscaling is reducing waste? Check GPU autoscaling efficiency by comparing paid GPU capacity and cost per successful request or completed job for equivalent workloads. Capacity use should fall without exceeding latency targets or increasing failures. Track successful requests or completed jobs, waiting time, latency, ready replicas, allocated nodes, and cost. Useful measures include cost per completed job or per successful request for a consistent request mix. Choose a unit that reflects your application's output. Test a steady load, a sharp burst, and a quiet interval. Include the time spent starting and shutting down capacity. Compare configurations against equivalent work so a lower bill caused by fewer requests is not mistaken for better efficiency. Define success before changing the policy: less paid capacity for the same useful output, while meeting the performance target. A policy that reduces GPU-hours by increasing failures or leaving work unfinished has not met that goal. ## How can Northflank support GPU autoscaling? Northflank supports GPU autoscaling through application metrics that control service replica counts and BYOC node-pool controls that adjust infrastructure capacity in your own cloud account. Your team configures the thresholds and limits around measured workload requirements. Start with the [GPU workload requirements](https://northflank.com/docs/v1/application/gpu-workloads/gpus-on-northflank) to choose a compatible application image and deployment target. For managed infrastructure, [deploy GPUs on Northflank Cloud](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-on-northflank-cloud) by creating a project in a GPU-enabled region and selecting an available GPU model and count for your service. In the service's resource settings, enable [horizontal autoscaling](https://northflank.com/docs/v1/application/scale/autoscale-deployments), set minimum and maximum instances, and configure the Prometheus endpoint and port, metric name, type, and threshold for a custom signal. When multiple metrics are enabled, Northflank uses the highest required instance count calculated from any of them. To [deploy GPUs in your own cloud account](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud), use a project on your GPU-enabled cluster and configure suitable [node pools](https://northflank.com/docs/v1/application/bring-your-own-cloud/deploy-and-scale-node-pools) and their scaling bounds. Northflank manages the configured pools; you control their resource choices and limits, and your cloud provider bills the infrastructure. Run the full traffic cycle before increasing the maximum. Your application team remains responsible for choosing meaningful metrics, measuring model performance, and handling startup and shutdown correctly. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss GPU scaling, workload placement, and capacity planning. ## Frequently asked questions about GPU autoscaling These questions help diagnose ineffective scaling policies. ### Is GPU utilization enough to decide when to scale? GPU utilization alone is not a reliable scaling signal for every inference workload because device activity does not directly measure spare serving capacity. Use it only after testing its relationship with latency and successful throughput; queue depth and active work can provide more useful demand signals. ### Does removing GPU pods reduce the cloud bill? Removing GPU pods reduces costs only when it reduces billable usage under your provider's pricing model. If the underlying nodes remain allocated, removing pods may leave the infrastructure charge unchanged. Check allocation and billing rather than inferring savings from replica count. ### Why are new GPU replicas running but not serving requests? GPU replicas can be running without serving requests because their applications are still initializing or loading model data. Configure readiness checks around the ability to accept useful work, and distinguish ready replicas from those that have merely started. ## Related articles about GPU infrastructure Use these guides to plan GPU infrastructure and compare capacity options. - [The complete guide to Kubernetes autoscaling](https://northflank.com/blog/the-complete-guide-to-kubernetes-autoscaling) - [On-demand vs reserved GPUs for AI workloads](https://northflank.com/blog/on-demand-vs-reserved-gpus) - [Which platforms support both CPU and GPU workloads in your own VPC?](https://northflank.com/blog/platforms-cpu-gpu-workloads-own-vpc) - [Best NVIDIA L4 GPU cloud providers for AI inference](https://northflank.com/blog/best-nvidia-l4-gpu-cloud-providers)

Northflank vs Runloop: AI sandboxes, pricing, and infrastructure compared

2026-09-23T15:15:00.000Z

## TL;DR: Northflank vs Runloop Northflank and Runloop both provide isolated execution environments for AI agents and untrusted code. Northflank combines [sandboxing](https://northflank.com/docs/v1/application/sandboxes/quickstart) and microVM-backed isolation with the infrastructure needed to run everything an AI agent creates, while Runloop focuses on Devbox environments for AI coding agents. - **Northflank combines [sandboxed execution](https://northflank.com/docs/v1/application/sandboxes/quickstart) with the rest of the application stack**, including [Cloud Harnesses](https://northflank.com/docs/v1/application/cloud-harness/quickstart), services, workers, jobs, managed databases, GPUs, persistent volumes, preview environments, templates, [BYOC, and BYOK](https://northflank.com/product/bring-your-own-cloud). - **Northflank extends sandboxing across the agent lifecycle**, from the coding environment where an agent works to the applications, jobs, databases, and other workloads it generates and runs in development and production. - **Runloop provides microVM-based Devbox infrastructure for AI coding agents**, with persistent environments, snapshots, and networking controls. > [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss AI infrastructure, security, compliance, or customer-cloud deployment. > Northflank and Runloop both provide isolated execution environments for AI agents and untrusted code, but they are built around different parts of the agent lifecycle. Runloop focuses on Devbox environments for AI coding agents, with microVM isolation. Northflank provides sandboxed infrastructure for the entire workload an agent operates on or generates, from the Harness where the agent runs to the services, databases, jobs, preview environments, and production workloads it deploys. Northflank has operated microVM isolation since 2021. As a multi-tenant infrastructure platform, isolating untrusted workloads has always been a core requirement rather than a capability added specifically for AI agents. Today, Northflank uses Kata Containers with Cloud Hypervisor as its primary microVM approach, with Firecracker and gVisor where supported. This lets Northflank apply sandboxing across the agent lifecycle instead of limiting isolation to the agent's coding environment. ## Why AI agents need more than a sandbox The term "AI agent sandbox" can make the infrastructure problem sound smaller than it is. An agent does not only execute code inside a sandbox. It can create services, provision databases, run jobs, install dependencies, call APIs, generate containers, create preview environments, and deploy applications. Once agents are responsible for creating and operating infrastructure, every workload they generate can be untrusted. That changes what sandboxing needs to cover. An agent might start inside a Cloud Harness, execute generated code inside a sandbox, deploy an API, provision a database, schedule a background job, and create a preview environment for someone to review. Eventually, that same application may be deployed to production. The security boundary should not stop at the first sandbox. If the agent is untrusted, the workloads it creates need appropriate isolation, networking, secrets, and access controls too. Northflank treats [sandboxing](https://northflank.com/docs/v1/application/sandboxes/quickstart) as a core infrastructure capability that extends across this execution chain. The platform provides the Harness where the agent works, microVM-backed sandboxes where it executes code, and the infrastructure around those sandboxes, including services, databases, jobs, GPUs, networking, previews, and production workloads. This is the key difference in approach between Northflank and Runloop. Runloop is built around the Devbox, where the coding agent executes. Northflank provides the sandbox and the infrastructure for the workloads that the agent creates. ## Northflank vs Runloop sandboxes: comparison table Product and plan details are current as of September 2026. | **Capability** | **Northflank** | **Runloop** | | --- | --- | --- | | **Platform scope** | Sandboxes plus application and AI infrastructure | Sandboxes for AI coding agents | | **Isolation** | Kata Containers with Cloud Hypervisor as the primary microVM based approach, with Firecracker and gVisor available | MicroVM based isolation | | **Lifecycle** | Short lived or long running workloads, scale to zero, restart, and destroy | Persistent Devboxes with suspend and resume | | **Environment creation** | API, CLI, SDKs, UI, Cloud Harnesses, and Templates | SDKs, API, and CLI | | **Compute** | CPU and GPU sandboxes | CPU Devboxes | | **Persistence** | Persistent volumes and reproducible infrastructure through templates and workflows | Persistent Devbox state and copy on write forking | | **Networking** | Private networking, DNS, network policies, public and private ports, and multi project connectivity | Devbox networking and egress policies | | **Supporting workloads** | Services, workers, jobs, databases, queues, object storage, GPUs, and other application workloads | Sandbox execution | | **Preview environments** | Full stack preview environments with applications, databases, jobs, volumes, and networking | NA | | **Infrastructure control** | Managed cloud, self serve BYOC, and BYOK | Managed infrastructure and Enterprise VPC deployment | | **Observability** | Logs, metrics, health checks, audit logs, log sinks, and infrastructure monitoring | Agent execution observability | | **Enterprise controls** | RBAC, SSO, audit logs, compliance controls, BYOC, and forward deployed options | Enterprise security, compliance, network controls, and VPC deployment | | **GPU workloads** | GPU Sandboxes, services, and jobs across managed cloud and BYOC | NA | | **Pricing model** | Per second CPU and memory pricing across sandbox and application workloads | Per second CPU and memory pricing | ## How do Northflank and Runloop compare on isolation? Both platforms use microVM-based isolation to separate sandbox workloads from the underlying host. Runloop provides a microVM for each Devbox, while Northflank uses Kata Containers with Cloud Hypervisor as its primary microVM-based isolation approach. Northflank also supports Firecracker and gVisor where supported. Northflank has used microVM-based sandbox orchestration in production since 2021. Because sandboxing is part of the underlying multi-tenant infrastructure, it is not limited to the environment where an AI agent executes code. The same infrastructure can isolate agent environments as well as the services, jobs, and other workloads those agents create. Runloop's model is centred on the individual Devbox where the coding agent runs. Its persistent environments, snapshots, and suspend and resume lifecycle make the Devbox the primary execution boundary. Northflank extends that boundary across the application stack, so the infrastructure generated by an agent can be sandboxed and managed alongside the environment where the agent itself runs. ## How do Northflank and Runloop compare on lifecycle and persistence? Runloop Devboxes can be suspended and resumed while preserving the environment's state. Snapshots can also capture disk state for creating new environments from an existing baseline. Northflank supports a different lifecycle model. Sandboxes and application workloads can be created, started, scaled to zero, restarted, and destroyed, while persistent volumes can retain data independently of the compute lifecycle. Templates and workflows can reproduce the surrounding infrastructure when a new environment is required. This distinction matters when an AI agent's work extends beyond a single coding session. Northflank can persist the data that needs to persist while independently managing the lifecycle of the sandbox, services, workers, jobs, databases, and other infrastructure the agent creates. The sandbox is not the boundary of the application. It is one part of the infrastructure Northflank can isolate and manage. ## How do Northflank and Runloop compare on startup and scaling? Northflank Sandboxes can start in under one second, while Northflank can also scale application workloads horizontally as demand changes. Its infrastructure supports container images, Dockerfiles, Buildpacks, registries, node pools, placement controls, and BYOC infrastructure. Runloop uses prebuilt blueprint images to prepare Devboxes with dependencies and environment configuration, and supports suspend and resume for returning to an existing environment. The difference is the scope of what is being scaled. Northflank can scale the sandbox alongside the application infrastructure around it, including services, workers, jobs, databases, and GPU workloads. The same infrastructure that provisions an agent environment can scale the workloads that the agent creates. ## How do Northflank and Runloop compare on storage, networking, and GPUs? Northflank Sandboxes use ephemeral root filesystems by default, with persistent volumes available when state needs to survive the sandbox lifecycle. Sandboxes can connect to other workloads through private networking, DNS, public and private ports, and network policies. This allows an isolated agent environment to interact with the databases and services it needs without putting those workloads on the public internet. Northflank also supports GPU Sandboxes and GPU workloads across managed cloud and BYOC infrastructure, including GPUs such as H100, H200, A100, L4, L40S, and B200. This allows the same infrastructure platform to run agent execution, model workloads, and production applications. Runloop provides persistent Devbox storage, networking, and controlled access to external services. GPU Devboxes are not supported. ## How do Northflank and Runloop compare on developer experience? Northflank supports Git based deployments, Dockerfiles, Buildpacks, external registries, Templates, Workflows, APIs, CLI, and SDKs. [Northflank Skills](https://github.com/northflank/skills) extend this workflow to tools such as Claude Code, Codex, Cursor, and OpenCode, while [Cloud Harnesses](https://northflank.com/docs/v1/application/cloud-harness/quickstart) provide isolated development environments for AI coding agents. Runloop provides SDKs, an API, CLI, and tools for building and interacting with Devboxes and agent workloads. Its platform also includes capabilities for agent evaluation and observability. The distinction is less about whether developers can create an isolated agent environment and more about what happens after the environment is created. Northflank connects agent execution directly to the infrastructure needed to build, deploy, and run the resulting application, including services, databases, jobs, GPUs, preview environments, and production workloads. ## How do Northflank and Runloop compare on previews and production infrastructure? A sandbox is useful for testing code in isolation, but AI agents can generate much more than code. A typical agent workflow can produce an API service, worker, database, scheduled job, persistent volume, and networking between those components. Northflank Preview Blueprints can reproduce that complete application topology for each branch or pull request, including applications, databases, jobs, volumes, private networking, and seed workflows. The same platform can then run those workloads in production, with the infrastructure controls needed throughout the lifecycle. Runloop is built around the Devbox and the infrastructure needed for agent development and evaluation rather than a full stack application preview and production platform. For teams building agent-generated applications, Northflank connects the sandbox to the infrastructure running everything the agent creates, from services and databases to jobs, previews, and production workloads. ## How do Northflank and Runloop compare on BYOC and infrastructure control? Runloop offers Deploy to VPC as an Enterprise offering. This allows Runloop infrastructure to run inside a customer's cloud environment with customer-managed network policies and data residency controls. Northflank has offered self-service production BYOC since 2019. Northflank can deploy its data plane into a customer's AWS, GCP, Azure, Oracle, CoreWeave, Civo, or Nebius account, allowing the customer to retain control of the underlying cloud account, VPC, billing relationship, and committed cloud spend. For environments with stricter requirements, Northflank also offers a forward-deployed control plane for regulated and air-gapped environments. The difference is particularly relevant for organizations that need their AI agent infrastructure to run inside their own cloud account rather than on shared infrastructure. ## How do Northflank and Runloop compare on security and observability? Runloop provides security controls around the Devbox, including microVM isolation, Agent Gateways for credential proxying, network egress policies, and VPC deployment on Enterprise. Runloop is SOC 2 Type II certified and HIPAA and GDPR compliant. Northflank provides security controls across both sandboxed workloads and the platform managing those workloads. RBAC applies at the organisation, team, project, and resource levels. SAML and OIDC SSO integrate with enterprise identity providers, while audit logs provide visibility from the organisation level down to individual resources and can be exported to SIEM systems. Northflank is SOC 2 Type 2 and HIPAA compliant, with Enterprise BAAs. The forward-deployed control plane supports environments that require the platform to operate without external network dependencies. The distinction is that Runloop's security model is closely tied to the Devbox and agent execution environment, while Northflank applies governance and security controls across the wider infrastructure lifecycle. That becomes increasingly important as agents move from writing code to provisioning and operating infrastructure. ## How do Northflank and Runloop compare on pricing? Northflank Cloud charges $0.01667 per vCPU hour and $0.00833 per GB hour for memory, billed per second. BYOC uses a separate platform pricing model, with cloud infrastructure billed directly by the underlying provider. Runloop charges $0.108 per CPU hour and $0.0252 per GB hour for memory, with storage billed separately. Suspended Devboxes do not incur compute and memory charges, although storage continues to be billed. For example, 200 continuously running workloads with 1 vCPU and 4 GB of memory for 720 hours would cost approximately $7,199 on Northflank compared with $30,067 on Runloop based on the published compute rates. That is approximately 76% lower on Northflank under these assumptions. Actual costs depend on CPU and memory allocation, storage, GPU usage, workload lifecycle, and infrastructure model. The broader difference is that Northflank pricing applies to the infrastructure primitives used across the application stack, so the same platform can handle sandbox execution alongside the services, databases, jobs, and other workloads an agent creates. ## Northflank vs Runloop: which approach fits your workload? Runloop is focused on Devbox infrastructure for AI coding agents, with microVM isolation, persistent environments, snapshots, networking, and tooling for agent development and evaluation. Northflank is designed for teams that need the sandbox and the infrastructure around it. Agents can work inside isolated environments, while the services, workers, jobs, databases, GPUs, previews, and other workloads they create can run through the same platform. The key difference is where the platform boundary ends. With Runloop, the Devbox is the primary execution environment for the agent. With Northflank, the sandbox is one infrastructure primitive within a broader application and AI platform, allowing teams to manage the agent, its execution environment, and the workloads it produces through the same control plane. ## FAQ: Northflank vs Runloop sandboxes ### What is the main difference between Northflank and Runloop sandboxes? Both provide microVM-based isolation for AI agent workloads. Runloop focuses on the Devbox where AI coding agents execute. Northflank provides microVM-backed sandboxes as part of a platform that can also run the services, databases, jobs, GPUs, previews, and production workloads generated by those agents. ### Is Northflank a Runloop alternative? Yes. Northflank provides CPU and GPU sandboxes alongside Cloud Harnesses, services, jobs, managed databases, networking, Preview Environments, Workflows, and BYOC. Runloop provides Devbox infrastructure focused on AI coding agent development, evaluation, and coordination. ### What makes Northflank's sandbox approach different? Northflank treats sandboxing as a core infrastructure capability. MicroVM isolation has been part of the platform since 2021 because Northflank has always needed to safely run untrusted workloads in a multi-tenant environment. For AI agents, that means the security boundary can extend beyond the agent's coding environment to the workloads the agent generates, including services, databases, jobs, preview environments, and production workloads. ### Does Runloop support BYOC? Runloop offers VPC deployment as an enterprise offering that runs Runloop infrastructure inside a customer's cloud environment. Northflank provides self-service BYOC across AWS, GCP, Azure, Oracle, CoreWeave, Civo, and Nebius. ### How does Runloop's suspend model compare to Northflank's scale-to-zero? Both can reduce the cost of inactive workloads. Runloop suspend stops compute and memory billing while preserving the Devbox state, with storage continuing to incur charges. Northflank scale-to-zero stops compute billing while attached persistent volumes are retained, and sandboxes can resume with sub-1-second boot times. The difference is that Northflank's scale-to-zero model applies across the wider application platform, including services, jobs, and other workloads, rather than only the coding environment.

Best persistent sandbox platforms for AI agents in 2026

2026-09-22T16:15:00.000Z

## TL;DR: Best persistent sandbox platforms for AI agents The best persistent sandbox depends on whether your AI agent needs saved files, preserved process memory, or a reusable snapshot, and how many tasks it must run at once. 1. **Northflank: Best for persistent AI agent sandboxes with no fixed session time limit.** A fit for teams that want isolated sandbox environments for AI agents and code execution, with fast startup, thousands of concurrent sessions, persistent volumes, and custom environments for coding agents, APIs, scripts, and GPU tasks. 2. **Fly.io Sprites: Best for persistent Linux workspaces that idle between tasks.** A fit for teams that need project files and installed tools to survive inactivity, with filesystem checkpoints for rollback. 3. **E2B: Best for preserving agent memory and files between tasks.** A fit for teams that need pause and resume to retain process state, with session limits that depend on the plan. 4. **Modal: Best for snapshot-based agent environments and GPU workloads.** A fit for teams that want reusable filesystem snapshots, persistent volumes, and SDK-configured execution environments. Follow the [Northflank sandbox quickstart](https://northflank.com/docs/v1/application/sandboxes/quickstart) to get started, [create an account](https://app.northflank.com/signup), or [talk to an engineer](https://cal.com/team/northflank/northflank-demo) about your agent’s persistence and concurrency requirements. *A comparison of the best persistent sandbox platforms for AI agents in 2026, covering how persistence works on each platform, GPU support, bring your own cloud (BYOC), and which use cases each fits.* Persistent sandboxes have moved from a niche requirement to something a lot of production AI agent teams are actively evaluating. The reasons are practical: agents that build up a working environment incrementally, maintain a filesystem between executions, or run long-horizon tasks need somewhere to keep state. Ephemeral-only platforms force you to engineer around that. The platforms covered here approach persistence differently. Some keep filesystem state via volumes. Some offer full pause/resume including memory. Startup speed, concurrency, and support for custom agent environments also vary. This article covers what each platform actually does so you can evaluate them against your specific requirements. If you're new to the concept, [what are persistent sandboxes](https://northflank.com/blog/persistent-sandboxes) covers the fundamentals before you get into platform comparisons. ## What are the key things to evaluate before choosing a persistent sandbox platform? Not all persistent sandboxes work the same way under the hood, and the differences matter when you're building production agent workflows. - **What actually persists?** Some platforms persist only the filesystem. Others persist filesystem and memory including running processes. Others use snapshots to create new environments from a saved state. These are meaningfully different capabilities. - **Is there a session time cap?** Some platforms impose a continuous runtime limit before you have to pause. Others impose no fixed session time limit. File retention and uninterrupted process execution are separate considerations. - **What's the isolation model?** MicroVM-based isolation (Firecracker, Kata Containers) and user-space kernel sandboxing (gVisor) offer different tradeoffs between security, performance, and compatibility. - **Do you need GPU access?** Not all sandbox platforms support GPU workloads. If your agents run inference or training, this narrows the list. - **Can you deploy in your own infrastructure?** If your organisation requires execution inside infrastructure it controls, check bring your own cloud (BYOC) support and the provider’s responsibilities. - **How quickly can it run your agent workload at scale?** Check sandbox startup time, concurrency limits, and custom environment support for coding agents, APIs, scripts, and GPU tasks. ## What are the top persistent sandbox platforms for AI agents in 2026? The platforms below cover the main options for teams evaluating persistent sandbox infrastructure today. Each takes a different approach to persistence, isolation, and deployment. ### 1. Northflank [Northflank](https://northflank.com/product/sandboxes) provides isolated sandbox environments for AI agents and code execution, with fast startup and support for thousands of concurrent sessions. Run coding agents, scripts, generated APIs, repository builds, and GPU tasks in custom environments, with persistent files for work that continues across sessions. **How persistence works:** Attach persistent volumes to retain repositories, generated files, and task artifacts across restarts and pauses. Save files that must survive to the mounted volume: ephemeral files are lost when a sandbox pauses. Pausing stops running processes and terminal sessions; it does not save RAM. Sandboxes have no fixed session time limit. ![northflank-sandbox-page.png](https://assets.northflank.com/northflank_sandbox_page_dd9fa07375.png) **Key Northflank offerings:** - **Environments:** Persistent and ephemeral sandboxes, configured per workload. - **Storage:** Persistent volumes up to 64 TB, multi-read-write support, and S3-compatible object storage for artifacts and generated files. - **Isolation:** Northflank Cloud uses microVMs for CPU sandboxes and gVisor for GPU sandboxes. - **Deployment:** Self-serve [bring your own cloud (BYOC)](https://northflank.com/product/bring-your-own-cloud), where Northflank acts as the control plane to run coding agents and their sandboxes in your virtual private cloud (VPC). Sandbox isolation requires a supported runtime on your infrastructure. - **GPU:** On-demand GPU execution for agent tasks that need accelerated compute. - **Access:** APIs, SDKs, and CLI tools for creating environments, executing commands, and managing files. - **Compliance:** [SOC 2 Type II and HIPAA compliant](https://northflank.com/security), with Business Associate Agreements (BAAs) supported under Enterprise contracts. - **Startup and concurrency:** Sub-second sandbox boot times on Northflank Cloud, with support for thousands of concurrent sessions. - **Custom workloads:** Run coding agents, generated APIs, scripts, test suites, and GPU tasks using your own container images. **Pricing:** $0.01667/vCPU-hour, $0.00833/GB-hour, with H100 GPU plans at $2.74/hour all-inclusive (CPU and RAM included). The free developer Sandbox tier includes always-on compute with no sleeping, two free services, one database, and two cron jobs for development and testing. Pay-as-you-go offers self-service CPU and GPU workloads, per-second billing, no seat-based fees, and autoscaling. Enterprise plans offer custom pricing, volume discounts, 24/7 support, service-level agreements (SLAs), single sign-on (SSO), and audit logs. [See the full pricing details](https://northflank.com/pricing) for additional GPU options and compute plans. **Running AI agents in production?** Northflank sandboxes combine persistent files, fast startup, high concurrency, and custom environments for AI agents and code execution. Run short-lived tasks or keep agent environments running without a fixed session cutoff. - [Sandbox environments overview](https://northflank.com/product/sandboxes): how persistent and ephemeral environments work on Northflank - [Get started](https://app.northflank.com/signup): self-serve setup - [Pricing](https://northflank.com/pricing): CPU, memory, and GPU pricing - [Talk to an engineer](https://cal.com/team/northflank/northflank-demo): for specific infrastructure or compliance requirements ### 2. Fly.io Sprites Fly.io Sprites are persistent Linux microVMs built by Fly.io that hibernate when idle and wake on demand. - **Filesystem:** Persists across hibernation (files, installed packages, git repos, and databases on disk all survive) - **Memory:** A warm pause freezes RAM and processes, which resume on a warm wake. A later cold transition discards memory and restarts processes. The platform controls that transition, so memory is not durable across all idle periods. - **Network config:** Open ports and URL settings persist across hibernation - **Storage:** 100 GB filesystem per Sprite, with a local cache backed by durable object storage - **Wake time:** Fly.io describes normal wakes of 100–500 ms and cold starts of 1–2 seconds; requests to a Sprite’s HTTPS URL can wake it automatically - **Checkpoints:** Save filesystem state without interrupting the running environment; process memory is not included - **Services:** Defined processes that restart after a cold wake, allowing servers to return when the environment resumes - **Isolation:** Firecracker microVMs - **GPU:** Not supported on Sprites - **Bring your own cloud (BYOC):** Not available (runs on Fly.io's managed infrastructure) ### 3. E2B E2B provides sandboxed code execution with a pause/resume model that preserves filesystem and memory state. - **Filesystem:** Persists on pause/resume - **Memory:** Normal pause preserves memory and running processes. Filesystem-only pause saves files but reboots on resume, losing memory state. - **Paused sandbox retention:** Kept indefinitely, no automatic deletion - **Continuous runtime cap:** 24 hours on Pro and 1 hour on Hobby, with longer Enterprise options - **Snapshots:** Available as a separate feature. Saves filesystem and memory state and can be used to create new sandboxes from a saved state. - **Isolation:** Firecracker microVMs - **GPU:** Not supported in sandboxes - **Bring your own cloud (BYOC):** AWS, GCP, and Azure on Enterprise ### 4. Modal Modal supports persistent agent environments through filesystem snapshots, directory snapshots, memory snapshots, and mounted volumes. - **Filesystem Snapshots:** Save the root filesystem as an image for new sandboxes. Default retention is 30 days; expiry can be changed or disabled. - **Directory Snapshots:** Save a selected directory for use in another sandbox. Default retention is 30 days; expiry can be changed or disabled. - **Memory Snapshots:** Alpha. Save filesystem and memory state for up to seven days. Snapshotting terminates the sandbox, excludes GPU support, and does not properly restore background processes launched through command execution. - **Volumes:** Network filesystems (Modal Volumes) can be mounted into sandboxes for persistent storage - **Isolation:** gVisor for standard sandboxes; CPU-only VM Sandboxes are also available in beta - **GPU:** Supported across the platform, but not available when memory snapshots are enabled - **Bring your own cloud (BYOC):** Not available - **SDK model:** Python, JavaScript, and Go clients, with support for custom container images - **Session limit:** Up to 24 hours per sandbox; saved files can be used in another sandbox ## How do persistent sandbox platforms compare on pricing? Pricing checked in September 2026. Hourly equivalents are rounded where needed. Billing models differ across platforms (some bill based on active CPU usage only, others bill for the entire duration the sandbox is running). Verify current rates on each platform's pricing page before making cost decisions. | Platform | CPU | Memory | Storage | GPU | Billing model | | --- | --- | --- | --- | --- | --- | | **Northflank** | $0.01667/vCPU-hr | $0.00833/GB-hr | $0.15/GB-month | L4: $0.80/hr, A100 40GB: $1.42/hr, A100 80GB: $1.76/hr, H100: $2.74/hr | Per second | | **E2B** | $0.0504/vCPU-hr | $0.0162/GiB-hr | 10 GiB Hobby / 20 GiB Pro included | Do not provide GPU compute | Per second; Pro adds $150/month plus usage | | **Fly.io Sprites** | $0.07/CPU-hr | $0.04375/GB-hr | $0.000683/GB-hr hot; $0.000027/GB-hr cold | Do not provide GPU compute | Actual usage, metered hourly; idle compute is free, retained storage is billed | | **Modal Sandboxes** | $0.1419/physical core-hr (2 vCPU) | $0.0240/GiB-hr | Volumes: $0.09/GiB-month; 1 TiB/month included | L4: $0.80/hr, A100 40GB: $2.10/hr, A100 80GB: $2.50/hr, H100: $3.95/hr, H200: $4.54/hr | Per second | Modal charges per physical core (two vCPUs). **Fly.io Sprites pricing update:** From October 1, 2026, CPU costs $0.03825/CPU-hour and memory costs $0.021875/GB-hour. Storage rates remain unchanged. ## Bring your own cloud (BYOC) support across persistent sandbox platforms The table below shows how each platform handles bring your own cloud (BYOC) deployment, which clouds are supported, and whether it requires a sales process. | Platform | Bring your own cloud (BYOC) available | Clouds supported | Access model | Pricing model | | --- | --- | --- | --- | --- | | **Northflank** | Yes, fully self-serve | AWS, GCP, Azure, and supported Kubernetes infrastructure, including on-premises and bare-metal | Self-serve, enterprise contracts available for larger commits (with bulk discounts) | Cloud infrastructure costs plus Northflank management charges | | **E2B** | Yes, limited and not self-serve | AWS, GCP, and Azure | Not publicly disclosed, need to contact sales | Custom Enterprise pricing plus cloud infrastructure costs | | **Modal** | No | Managed only | — | — | | **Fly.io Sprites** | No | Managed only | — | — | ## Which persistent sandbox platform fits your situation? Here's a quick reference for matching your use case to the right platform. | If your situation is... | Consider... | | --- | --- | | You need persistent and ephemeral AI agent sandboxes with custom environments | Northflank | | You need self-serve deployment of AI agent sandboxes in your own virtual private cloud (VPC) | Northflank | | You need GPU execution with persistent sandbox files | Northflank or Modal | | You need fast sandbox execution for AI-generated code and agent workloads at high concurrency | Northflank | | You need filesystem state to survive between executions with no session cap | Northflank or Fly.io Sprites | | You need saved memory and process state across an explicit pause/resume | E2B; Sprites preserves these during warm pauses only | | You need to save a filesystem snapshot and spin up new sandboxes from it | Modal (Filesystem Snapshots) | | You want a persistent Linux environment that hibernates when idle and wakes on demand | Fly.io Sprites | | Your workloads are Python-first and primarily ML/inference | Modal | ## FAQ: best persistent sandbox platforms ### Which persistent sandbox platform is best for enterprise teams? Northflank is a strong fit for enterprise teams that need persistent AI agent sandboxes, high concurrency, custom environments, and GPU execution. It is SOC 2 Type II and HIPAA compliant, with Business Associate Agreements (BAAs) supported under Enterprise contracts. With bring your own cloud (BYOC), Northflank acts as the control plane to run coding agents and their sandboxes in your virtual private cloud (VPC). ### Do any of these platforms support GPU workloads in persistent sandboxes? Northflank supports GPU workloads in both persistent and ephemeral environments. Modal supports GPUs but sandboxes with memory snapshot support enabled cannot run with GPUs. Fly.io Sprites are CPU-only. E2B does not support GPU sandboxes. ### Can I use both persistent and ephemeral sandboxes on the same platform? Yes. Northflank supports both, configured per workload: attach a volume for files you need to retain, or use an ephemeral sandbox for a disposable task. E2B and Modal also support disposable execution and persistence through their pause or snapshot features. ### How long do persistent sandboxes last on each platform? Northflank has no fixed session time limit, and attached-volume files survive pauses and restarts. Fly.io Sprites retains its filesystem when compute idles; warm pauses preserve memory and processes, but cold transitions discard them. E2B retains paused sandboxes indefinitely, with active session limits depending on the plan. Modal sandboxes run for up to 24 hours; filesystem and directory snapshots default to 30-day retention with configurable expiry, while memory snapshots expire after seven days. ## Related articles on persistent sandbox platforms and sandbox infrastructure - [What are persistent sandboxes?](https://northflank.com/blog/persistent-sandboxes): The foundational explainer on what persistent sandboxes are, how they differ from ephemeral environments, and when you need them. - [Ephemeral sandbox environments](https://northflank.com/blog/ephemeral-sandbox-environments): Covers how ephemeral sandboxes work and when they're the right choice over persistent ones. - [E2B vs Modal vs Fly.io Sprites](https://northflank.com/blog/e2b-vs-modal-vs-fly-io-sprites): A deeper comparison of three of the platforms covered in this article, with more detail on isolation models and use case fit. - [E2B vs Sprites dev](https://northflank.com/blog/e2b-vs-sprites-dev): A head-to-head comparison of E2B and Fly.io Sprites, covering persistence approach, isolation, and use case differences. - [Self-hosted AI sandboxes](https://northflank.com/blog/self-hosted-ai-sandboxes): Covers the self-hosted and bring your own cloud (BYOC) route for teams with compliance or data residency requirements. - [Top AI sandbox platforms for code execution](https://northflank.com/blog/top-ai-sandbox-platforms-for-code-execution): A broader overview of sandbox platforms for code execution beyond the persistence-focused platforms covered here. - [Best code execution sandbox for AI agents](https://northflank.com/blog/best-code-execution-sandbox-for-ai-agents): A platform comparison for agent builders evaluating code execution sandbox options.

How do ephemeral environments reduce infrastructure costs?

2026-09-22T16:00:00.000Z

## TL;DR: how ephemeral environments reduce infrastructure costs - **Persistent environments accumulate infrastructure costs** even when nobody is using them. Idle compute, overprovisioned resources, and environments that are left running after work is complete all contribute to unnecessary spend. - **Ephemeral environments reduce this waste** by provisioning infrastructure on demand and automatically managing its lifecycle. TTLs, automatic teardown, scale-to-zero, database forking, and path filters can further reduce resource usage. - [**Northflank provides full-stack ephemeral environments**](https://northflank.com/product/preview-environments) with automatic provisioning and teardown, resource controls, database forking, and preview blueprints, so teams can create isolated environments for each pull request without turning every environment into permanent infrastructure. > **What is Northflank?** [Northflank](https://northflank.com/) is a cloud platform for building, deploying, and running applications, with infrastructure for [ephemeral environments](https://northflank.com/product/preview-environments), [managed databases](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), [GPUs](https://northflank.com/product/gpu-paas), jobs, and more. Run full-stack [preview environments](https://northflank.com/product/preview-environments) on [Northflank's managed cloud](https://northflank.com/features/managed-cloud) or [in your own cloud account](https://northflank.com/features/bring-your-own-cloud). [Get started with Northflank](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > Most staging environments run continuously. They are provisioned once, sized for peak load, and left running through nights, weekends, and public holidays. The applications deployed on them may be actively used for only a few hours each working day. The rest of the time, compute is running at low utilization, databases are holding connections, and cloud bills are accumulating for work nobody is doing. Ephemeral environments change the cost model. Instead of maintaining always-on infrastructure, environments are provisioned on demand when a pull request opens and torn down automatically when it closes. This reduces compute costs by aligning infrastructure usage with the time a workload is actually active, rather than keeping resources running while an environment sits idle. ## What is an ephemeral environment? An ephemeral environment is a short-lived, isolated environment provisioned on demand for a specific purpose and automatically destroyed when that work is complete. In a development workflow, the most common example is a preview environment: a complete deployment of an application created when a pull request opens, used for testing and review, and torn down when the PR merges or closes. Ephemeral environments differ from persistent environments such as staging and QA because they are designed to be temporary from the start. They are not intended to accumulate state, require ongoing maintenance, or keep running when nobody is using them. The lifecycle is simple: create, use, destroy. The cost follows the same lifecycle, with resources available when they are needed and released when they are not. ## How do ephemeral environments compare to persistent environments on cost? The cost difference between ephemeral and persistent environments is not primarily about the compute rate per hour. It is about how long the infrastructure actually runs and how much of that time it is being used. A persistent staging environment can consume compute, memory, database, and storage resources continuously, even when nobody is using it. An ephemeral environment ties those resources to a specific workload, allowing teams to provision them when needed and remove them when the work is complete. | Cost factor | Persistent environment | Ephemeral environment | | --- | --- | --- | | **Idle compute** | Runs continuously, including nights and weekends | Runs only while the environment is needed | | **Database costs** | Database remains provisioned continuously | Database can be created or forked for the environment and removed when it is no longer needed | | **Orphaned resources** | Resources can remain after a branch or test is abandoned | Automatic teardown or TTLs can remove unused environments | | **Overprovisioning** | Resources are often sized for a broad range of workloads | Resources can be right-sized for each environment | | **Concurrent environments** | Teams may share a small number of persistent environments | Each PR or workload can have its own environment when required | The key difference is simple: persistent environments pay continuously, while ephemeral environments can release resources when the workload is finished. The more time an environment would otherwise spend idle, the greater the potential for cost savings. ## How do ephemeral environments reduce infrastructure costs? Ephemeral environments reduce infrastructure costs by controlling how long resources run, how much capacity they use, and when they are removed. The key controls are automatic teardown, TTLs, scale to zero, database forking, and selective builds. 1. **Automatic teardown on PR close:** When a pull request is merged or closed, its environment can be torn down automatically. This releases compute, databases, storage, and other resources without requiring manual cleanup. It also prevents resources from continuing to run after the work they were created for is finished. 2. **TTLs and auto expiry:** A time to live (TTL) puts a maximum lifetime on an environment. This is useful for long-running pull requests, temporary test environments, and abandoned branches where the normal teardown trigger may not happen. Once the TTL is reached, the environment can be automatically removed. 3. **Scale to zero:** Not every environment needs to be running at full capacity all the time. Services that are not receiving traffic can scale to zero, reducing compute usage while keeping the environment configuration available to start again when needed. This can be useful for preview environments that remain open but are only accessed occasionally. 4. **Database forking:** Instead of maintaining a separate full-size database for every environment, teams can create isolated database forks for testing. These can be based on existing database data and removed when the environment is torn down, reducing the resources required to maintain persistent database copies. 5. **Path filters and selective builds:** In a monorepo, a pull request may change only a small part of the application. Path filters can limit builds and deployments to the services affected by those changes, avoiding unnecessary build and compute usage for unrelated services. ## The trade-offs: cost, fidelity, startup time, and isolation Ephemeral environments can reduce infrastructure costs, but they are not automatically cheaper in every configuration. The cost depends on how much infrastructure each environment provisions and how long it runs. The main trade-offs are fidelity, startup time, and isolation. - **Fidelity vs cost:** A full fidelity environment can run every service the application depends on and use a realistic database, making it useful for testing complex changes. A lighter environment can use fewer services, smaller resources, or seeded test data to reduce cost and start faster. The right level of fidelity depends on what the pull request changes. A frontend change may not need the same infrastructure as a database migration or backend change. - **Startup time vs cost:** Larger environments, more services, large container images, and database restoration can increase the time it takes to provision an environment. Prebuilt images, caching, smaller resources, and selective builds can reduce this overhead. Teams need to balance how quickly an environment becomes available with how much infrastructure they provision. - **Isolation vs cost:** Giving every pull request its own services, database, and supporting infrastructure provides stronger isolation but also requires more resources. Sharing some resources can reduce costs, but introduces dependencies between environments. The right level of isolation depends on the workload and what needs to be tested independently. - **AI-generated PR volume:** AI coding agents can increase the number of pull requests and temporary environments a team creates. At higher volumes, the cost of each environment becomes more important. Controls such as TTLs, automatic teardown, selective builds, scale to zero, and different environment configurations can help teams manage that growth without keeping every environment running at full capacity. ## How Northflank handles ephemeral environment cost controls Northflank provisions [full-stack preview environments](https://northflank.com/product/preview-environments) for pull requests and branches using [preview blueprints](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints). A blueprint defines the resources that should be created for each environment, including services, databases, jobs, volumes, and networking. When a preview is created, these resources are provisioned together as an isolated environment, and they can be removed automatically when the preview is no longer needed. - **Automatic cleanup:** Northflank can automatically delete preview environments when the associated pull request closes, or its branch is deleted. When a preview is deleted, its services, databases, volumes, and other resources are removed with it. This prevents resources from remaining active after the development work is complete. - **Preview expiry:** Preview blueprints support automatic expiry after a configured lifetime. The expiry timer can also be reset when the preview is updated, allowing active environments to remain available while still putting a limit on how long unused previews can exist. - **Teardown schedules:** Preview environments can be configured to shut down during periods when they are not needed, such as nights and weekends. This is useful when teams want to keep previews available without running their full infrastructure continuously. - **Right-sized resources:** Preview environments do not need to use the same resource plans as production. Northflank recommends using smaller resource plans for previews where appropriate, allowing teams to match CPU and memory allocation to the workload being tested rather than provisioning production-sized infrastructure for every pull request. - **Database isolation:** Databases can be included directly in Preview Blueprints, so each preview environment can have its own isolated database alongside the application services. The database is then removed when the preview is deleted. Northflank supports multiple database types for this model, including PostgreSQL, MySQL, MongoDB, Redis, MinIO, and RabbitMQ. - **Path filters and selective builds:** Northflank supports per-service path filters that determine which file changes should trigger a build. In a monorepo, this means a pull request that changes one service does not need to rebuild unrelated services, reducing both preview creation time and build compute. - **Concurrency controls:** Teams can also limit the number of concurrent preview environments. This provides another layer of cost control when a repository has many open pull requests or generates previews frequently. - **Bring Your Own Cloud (BYOC):** With [Northflank BYOC](https://northflank.com/product/bring-your-own-cloud), preview environments can run in your own cloud account, with support for providers including AWS, GCP, Azure, Oracle, CoreWeave, Civo, and Nebius. Existing Kubernetes infrastructure, including on-premises and bare-metal environments, can be connected through BYOK. Together, these controls let teams decide how much infrastructure each ephemeral environment should use and how long it should exist. The result is not simply a temporary copy of staging, but an environment with a defined lifecycle and resource policy. ## Conclusion Ephemeral environments can reduce infrastructure costs by tying resource usage to actual development work instead of keeping staging infrastructure running continuously. Automatic teardown, TTLs, right-sized resources, selective builds, and database isolation help limit how much infrastructure each environment consumes and how long it remains active. The goal is not simply to make environments temporary, but to give each environment a lifecycle that matches the work it supports. [Northflank](https://northflank.com/) provides [full-stack ephemeral environments](https://northflank.com/product/preview-environments) with the controls needed to manage that lifecycle. Teams can automatically create isolated environments for pull requests, right-size their resources, set expiry and teardown schedules, and clean up environments when they are no longer needed. > [Start building ephemeral environments with Northflank](https://app.northflank.com/signup) to reduce wasted infrastructure while keeping every pull request isolated and ready to test, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to see how Northflank can fit into your development workflow. > ## FAQs: ephemeral environment cost ### What is an ephemeral environment? An ephemeral environment is a short-lived, isolated infrastructure environment that is provisioned on demand for a specific purpose and removed when that work is complete. In a development workflow, the most common example is a preview environment created for a pull request and removed when the pull request closes. ### Why are persistent staging environments expensive? Persistent staging environments continue running even when nobody is actively using them. Compute, databases, storage, and other resources can remain provisioned during nights, weekends, and periods of low activity. Resources can also remain active after they are no longer needed if they are not cleaned up manually. ### How much can ephemeral environments reduce infrastructure costs? There is no fixed percentage because the savings depend on how the existing infrastructure is used. The biggest opportunity usually comes from environments that spend significant amounts of time idle. Provisioning resources only when they are needed, right-sizing them for the workload, and removing them automatically can reduce the amount of infrastructure that remains active without being used. ### What is the difference between TTLs and automatic teardown? Automatic teardown removes an environment when a specific event occurs, such as when a pull request is merged or closed. A TTL, or time to live, sets a maximum lifetime for an environment regardless of whether that event occurs. Using both provides a normal cleanup mechanism for completed work and a safety net for environments that remain open longer than expected. ### Do ephemeral environments always cost less than persistent environments? Not necessarily. Ephemeral environments can reduce costs by running infrastructure for less time and by allowing resources to be sized for specific workloads, but a full fidelity environment with many services and databases can still consume significant resources. The cost advantage comes from combining ephemeral environments with lifecycle and resource controls such as automatic teardown, TTLs, right-sizing, selective builds, and database isolation. ## Related articles - [How to auto create preview environments on every PR](https://northflank.com/blog/how-to-auto-create-preview-environments-on-every-pr) - [Which database strategy should you use for preview environments?](https://northflank.com/blog/which-database-strategy-should-you-use-for-preview-environments) - [How to build efficient monorepo preview environments](https://northflank.com/blog/how-to-build-efficient-monorepo-preview-environments)

Northflank vs Blaxel: AI sandboxes, pricing, and infrastructure compared

2026-09-22T14:00:00.000Z

## TL;DR: Northflank vs Blaxel Northflank and Blaxel both provide isolated execution environments for AI agents and untrusted code. Northflank combines sandboxing and microVM-backed isolation with the broader infrastructure needed to build, deploy, and run AI applications, while Blaxel focuses on persistent sandbox environments for agent workloads. - **Northflank combines sandboxed execution with the rest of the application stack**, including Cloud Harnesses, services, workers, jobs, managed databases, GPUs, persistent volumes, Preview Environments, Workflows, BYOC, and BYOK. - **Northflank extends isolation across the agent lifecycle**, from the coding environment where an agent works to the applications, jobs, databases, and other workloads it generates and runs in development and production. - **Blaxel provides microVM-based sandbox infrastructure** with persistent state, standby and resume, storage, and networking. Blaxel was acquired by Baseten on September 10, 2026. > [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss AI infrastructure, security, compliance, or customer-cloud deployment. > Northflank and Blaxel both provide isolated sandbox environments for AI agents and untrusted code execution. Northflank integrates sandboxes and microVM-backed isolation into a broader application and AI infrastructure platform, while Blaxel focuses on persistent sandbox environments. On September 10, 2026, Baseten acquired Blaxel. Northflank has run production microVM sandbox orchestration since 2021, with isolated execution built into its multi-tenant platform. Today, [Northflank Sandboxes](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-on-northflank) and [Cloud Harnesses](https://northflank.com/docs/v1/application/cloud-harness/quickstart) provide isolated environments for AI agents and development, while the same control plane can run the services, jobs, databases, GPUs, and other workloads those agents generate. This comparison looks at how Northflank and Blaxel differ across isolation, lifecycle, startup and scaling, networking, GPUs, the full agent execution stack, infrastructure control, security, observability, and pricing. ## Why AI agents need more than a sandbox AI agents increasingly do more than execute a single piece of code. An agent can create an API, start a worker, run a database migration, provision a database, execute background jobs, download data, or deploy an application. Those workloads are generated by the agent, so they should be treated as untrusted too. Northflank treats sandboxing as a security boundary around the entire workload. Cloud Harnesses provide an isolated environment for agents to work in, while Sandboxes, services, jobs, databases, volumes, networking, and GPUs can run through the same control plane. This means you can isolate both the agent and the infrastructure it creates, from development through production. Blaxel focuses on persistent microVM sandbox environments for agent execution. That provides isolated compute with persistent state, but the resulting application infrastructure still needs somewhere to run. With Northflank, the sandbox is not the destination. It is the security boundary around the entire agent-generated workload. ## Northflank vs Blaxel sandboxes: comparison table Product and plan details are current as of September 2026. | Capability | Northflank | Blaxel | | --- | --- | --- | | **Platform scope** | Sandboxes plus application and AI infrastructure | Sandbox infrastructure | | **Isolation** | Kata Containers with Cloud Hypervisor as the primary microVM-based approach, with Firecracker and gVisor available | microVM-based isolation | | **Lifecycle** | Short lived or long running workloads, scale to zero, restart, and destroy | Persistent sandboxes with standby and resume | | **Environment creation** | API, CLI, SDKs, UI, Cloud Harnesses and Templates. | SDKs, API, and CLI | | **Compute** | CPU and GPU sandboxes | CPU sandbox | | **Persistence** | Persistent volumes and reproducible infrastructure through templates and workflows | Persistent sandbox by default | | **Networking** | Private networking, DNS, network policies, public and private ports, and multi project connectivity | Sandbox networking, proxy access, and ports. | | **Supporting workloads** | Services, workers, jobs, databases, queues, object storage, GPUs, and other application workloads | Sandbox execution | | **Preview environments** | Full-stack preview environments | NA | | **Infrastructure control** | Managed cloud, self-serve BYOC, and BYOK | Managed infrastructure; BYOC through custom offering | | **Observability** | Logs, metrics, health checks, audit logs, log sinks, and infrastructure monitoring | Sandbox logs and resource metrics | | **Enterprise controls** | RBAC, SSO, audit logs, compliance controls, BYOC, and enterprise deployment options | Enterprise security and compliance capabilities | | **Pricing model** | Per second compute pricing with CPU and memory based billing | Sandbox compute tiers | ## How do Northflank and Blaxel compare on isolation? Both platforms use microVM-based isolation to separate sandbox workloads from the underlying host. Blaxel provides a microVM for each sandbox, while Northflank uses Kata Containers with Cloud Hypervisor as its primary microVM-based isolation approach. Northflank also supports Firecracker and gVisor. Northflank has used microVM-based sandbox orchestration in production since 2021. Because sandboxing is part of the underlying multi-tenant infrastructure, the same isolation model can be applied to agent environments as well as the services, jobs, and other workloads those agents create. Blaxel's model is centred on the individual sandbox. Its persistent environments preserve state between executions, making the sandbox itself the primary execution boundary. Northflank extends that boundary across the application stack. ## How do Northflank and Blaxel compare on lifecycle and persistence? Blaxel sandboxes are designed to persist. Sandboxes can enter standby after inactivity and resume quickly while preserving memory and process state. Blaxel also provides persistent storage through volumes and Agent Drive. Northflank supports a different lifecycle model. Sandboxes and application workloads can be created, started, scaled to zero, restarted, and destroyed, while persistent volumes can retain data independently of the compute lifecycle. Templates and Workflows can reproduce the surrounding infrastructure when a new environment is required. This distinction matters when an agent's work extends beyond a single sandbox session. Northflank can persist the data that needs to persist while independently managing the lifecycle of the application, workers, jobs, databases, and other infrastructure around it. ## How do Northflank and Blaxel compare on startup and scaling? Northflank Sandboxes can start in under one second, while Northflank can also scale application workloads horizontally as demand changes. Its infrastructure supports container images, Dockerfiles, Buildpacks, registries, node pools, placement controls, and BYOC infrastructure. Blaxel provides fast resume from standby, with resume times below 25 milliseconds, as well as sandbox forking and prebuilt environments. These capabilities are designed around quickly creating or resuming isolated agent environments. The difference is the scope of what is being scaled. Northflank can scale the sandbox alongside the application infrastructure around it, including services, workers, jobs, databases, and GPU workloads. ## How do Northflank and Blaxel compare on storage, networking, and GPUs? Northflank Sandboxes use ephemeral root filesystems by default, with persistent volumes available when state needs to survive the sandbox lifecycle. Sandboxes can connect to other workloads through private networking, DNS, public and private ports, and network policies. This allows an isolated agent environment to interact with the databases and services it needs without putting those workloads on the public internet. Northflank also supports GPU Sandboxes and GPU workloads across managed cloud and BYOC infrastructure, including GPUs such as H100, H200, A100, L4, L40S, and B200. This allows the same infrastructure platform to run agent execution, model workloads, and production applications. Blaxel provides persistent filesystem and volume options, sandbox networking, and proxy access. Blaxel does not support GPU Sandbox. ## How do Northflank and Blaxel compare on developer experience? Northflank supports Git-based deployments, Dockerfiles, Buildpacks, external registries, Templates, Workflows, APIs, CLI and SDKs. Northflank Skills extend this workflow to tools such as Claude Code, Codex, Cursor, and OpenCode, while [Cloud Harnesses](https://northflank.com/docs/v1/application/cloud-harness/quickstart) provide isolated development environments for AI coding agents. Blaxel provides SDKs, API, CLI, and MCP integrations. Agents can create and interact with sandbox environments directly through these interfaces. The distinction is less about whether developers can create a sandbox and more about what happens after the sandbox is created. Northflank connects agent execution directly to the infrastructure needed to build, deploy, and run the resulting application. ## How do Northflank and Blaxel compare on previews and production infrastructure? A sandbox is useful for testing code in isolation, but AI-generated applications often need more than an execution environment. A typical agent-generated application can include an API service, worker, database, scheduled job, persistent volume, and networking between those components. Northflank full-stack preview environments and preview blueprints can reproduce that complete application topology for each change. The same platform can then run the resulting workloads in production, with the isolation, networking, storage, observability, and scaling controls used throughout the lifecycle. Blaxel provides isolated sandbox execution rather than an equivalent full-stack application preview and production platform. For teams building agent-generated applications, this means the sandbox and the infrastructure running the resulting application are separate concerns. ## How do Northflank and Blaxel compare on BYOC and infrastructure control? Northflank supports self-service BYOC deployments across providers including AWS, GCP, Azure, Oracle, CoreWeave, Civo, and Nebius. Teams can run Northflank infrastructure in their own cloud accounts while retaining the Northflank control plane and deployment experience. Northflank also supports eligible existing Kubernetes clusters through BYOK, including infrastructure running across cloud, on-premises, and bare metal environments. This gives teams control over where workloads and data run without giving up the platform layer used to manage them. Blaxel primarily provides managed infrastructure, with BYOC available through its Custom offering. Northflank provides self-service BYOC across multiple cloud providers as well as BYOK and has been doing this since 2019. ## How do Northflank and Blaxel compare on security and observability? Northflank combines workload isolation with platform-level security controls. Organisations can use granular RBAC, SAML and OIDC SSO, audit logs, policy controls, and enterprise deployment options. Logs and metrics are available across services, jobs, builds, and other infrastructure, giving teams visibility beyond the sandbox itself. Blaxel provides security and compliance capabilities around its sandbox infrastructure, alongside sandbox logs and resource metrics. Its isolation model provides a dedicated execution boundary for each sandbox. For agent infrastructure, isolation is only one part of the security model. The infrastructure surrounding the sandbox also needs identity controls, auditability, networking policies, secrets management, observability, and production governance. Northflank brings those controls into the same platform used to run the workloads. ## How do Northflank and Blaxel compare on pricing? Northflank Cloud charges $0.01667 per vCPU hour and $0.00833 per GB hour for memory, billed per second. BYOC uses a separate platform pricing model, with cloud infrastructure billed directly by the underlying provider. Blaxel uses fixed sandbox memory tiers, with pricing ranging from its XS tier at $0.0828 per hour for 2 GB of memory to its XL tier at $1.3248 per hour for 32 GB. Its 4 GB tier costs $0.1656 per hour. Standby reduces compute charges while storage continues to be billed. For example, using 200 continuously running 4 GB sandboxes for 720 hours, Blaxel's published 4 GB tier would cost approximately $23,846 per month. A Northflank configuration using 2 vCPUs and 4 GB of memory for the same 200 workloads would cost approximately $9,599 per month based on the published compute rates. That is roughly 60% lower under these assumptions. The exact cost depends on CPU allocation, memory, storage, GPU usage, standby behaviour, and infrastructure model. The broader difference is that Northflank pricing covers the compute primitives used across the application stack, rather than requiring a separate platform for sandbox execution and another platform for the application infrastructure around it. ## Northflank vs Blaxel: which approach fits your workload? Blaxel is focused on persistent sandbox infrastructure for AI agents, with microVM isolation, persistent state, standby and resume, storage, and networking. Northflank is designed for teams that need the sandbox and the infrastructure around it. Agents can work inside isolated environments, while the services, workers, jobs, databases, GPUs, previews, and other workloads they create can run through the same platform. The key difference is where the platform boundary ends. With Blaxel, the sandbox is the primary product. With Northflank, the sandbox is one infrastructure primitive within a broader application and AI platform, allowing teams to manage the agent, its execution environment, and the workloads it produces through the same control plane. ## FAQ: Northflank vs Blaxel sandboxes ### What is the main difference between Northflank and Blaxel? Blaxel focuses on persistent microVM sandbox environments for AI agents. Northflank provides sandboxing as part of a broader application and AI infrastructure platform that also includes services, jobs, databases, GPUs, networking, previews, and production infrastructure. ### Is Northflank a Blaxel alternative? Yes. Northflank can provide isolated sandbox environments for AI agents while also providing the infrastructure needed to run the applications and workloads those agents create. ### Was Blaxel acquired? Yes. Baseten acquired Blaxel on September 10, 2026. ### Does Blaxel support BYOC? Yes. Blaxel offers Bring Your Own Compute through its Custom offering. Northflank provides self-service BYOC across multiple cloud providers as well as BYOK for eligible existing Kubernetes infrastructure and has been doing this since 2019. ### How do Northflank and Blaxel handle enterprise security? Both platforms provide security and compliance capabilities around isolated workloads. Northflank additionally provides platform-wide controls including granular RBAC, SSO, audit logs, networking controls, and enterprise deployment options across the workloads managed by the platform.

Northflank vs Daytona: sandboxes, pricing, and infrastructure compared

2026-09-21T17:45:00.000Z

## TL;DR: Northflank vs Daytona Northflank and Daytona both provide isolated sandbox environments for AI agents and untrusted code execution. Northflank integrates Sandboxes and microVM-backed isolation into a broader application and AI infrastructure platform, while Daytona focuses on programmable sandbox environments for AI-generated code. - **Northflank combines sandboxed execution with the rest of the application stack**, including Cloud Harnesses, services, workers, jobs, managed databases, GPUs, persistent volumes, Preview Environments, Workflows, BYOC, and BYOK. - **Northflank supports the full agent lifecycle**, from isolated coding environments to the workloads an agent generates and runs in development and production. - **Daytona provides programmable sandbox infrastructure** with persistent environments, snapshots, multiple sandbox types, and SDKs for managing sandbox workloads. > [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss AI infrastructure, security, compliance, or customer-cloud deployment. > Northflank and Daytona both provide isolated environments for running AI-generated and untrusted code. But as AI agents move from generating snippets to building and operating applications, sandboxing one agent process is no longer enough. The services, jobs, databases, and other workloads an agent creates can also be untrusted and need the same isolation, networking, resource controls, and observability. Northflank has run production workloads since 2019 and production microVM sandbox orchestration since 2021, with isolated execution built into its multi-tenant platform. Today, [Northflank Sandboxes](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-on-northflank) and [Cloud Harnesses](https://northflank.com/docs/v1/application/cloud-harness/quickstart) provide isolated environments for AI agents and development, while the same control plane can run the applications and infrastructure those agents generate. Daytona focuses on programmable sandbox infrastructure for AI-generated code. This comparison looks at how the two platforms differ across isolation, lifecycle, startup and scaling, networking, GPUs, developer experience, infrastructure control, security, observability, and pricing. ## Northflank vs Daytona: comparison table Product and plan details are current as of September 2026. | Requirement | Northflank | Daytona | | --- | --- | --- | | **Platform focus** | Sandboxes, Cloud Harnesses, and isolated application workloads in one control plane | Programmable sandbox infrastructure for AI-generated code execution | | **Isolation** | MicroVM isolation using Kata Containers with Cloud Hypervisor as the primary approach; Firecracker and gVisor where supported | Linux containers and VM sandboxes with multiple runtime options | | **Sandbox types** | CPU and GPU Sandboxes | Linux containers, Linux and Windows VMs, GPU, and macOS Sandboxes | | **Sandbox pricing** | $0.01667/vCPU-hour + $0.00833/GB-hour memory, billed per second on Northflank Cloud; BYOC platform fees plus infrastructure billed by the cloud provider | $0.0504/vCPU-hour + $0.0162/GiB-hour memory + $0.000108/GiB-hour storage after the first 5 GiB, billed per second; BYOC available through Enterprise | | **Startup** | Under 1 second | Under 90ms for Linux containers | | **Persistence** | Ephemeral root filesystem with optional persistent volumes; Templates and Workflows reproduce infrastructure | Persistent sandbox state, snapshots, volumes, and lifecycle controls | | **GPU** | GPU Sandboxes, model-serving services, and jobs across managed cloud and BYOC | NVIDIA and AMD GPU Sandboxes | | **Networking** | Private ports, multi-project networking, network policies, static egress, and BYOC networking | Per-sandbox network controls and sandbox networking | | **Developer experience** | Git, Dockerfiles, Buildpacks, API, CLI, SDKs, Templates, Workflows, GitOps, Skills, and Harnesses | API, CLI, SDKs, and sandbox tooling | | **Managed databases** | PostgreSQL, MySQL, MongoDB, Redis, RabbitMQ, MinIO, and more | Sandbox-focused platform | | **Preview environments** | Full-stack Preview Blueprints for applications and supporting infrastructure | Sandbox environments | | **BYOC** | Self-service across AWS, GCP, Azure, Oracle, CoreWeave, Civo, and Nebius | Bring Your Own Compute through Enterprise | | **BYOK** | Eligible existing Kubernetes clusters across cloud, on-premises, and bare-metal environments | Not available as the same Kubernetes-based model | | **Open source** | Proprietary platform | Production codebase moved to a private repository in June 2026; previous public repository is no longer maintained | | **Enterprise governance** | SOC 2 Type 2, HIPAA, granular RBAC, SAML/OIDC SSO, audit logs, and forward-deployed and air-gapped options | SOC 2, GDPR, HIPAA, and Enterprise security controls | ## How do Northflank and Daytona compare on isolation and sandbox types? Northflank uses [Kata Containers](https://northflank.com/blog/what-are-kata-containers) with [Cloud Hypervisor](https://northflank.com/blog/guide-to-cloud-hypervisor) as its primary microVM approach, giving sandboxes hardware-level kernel isolation by default. [Firecracker](https://northflank.com/blog/what-is-aws-firecracker) and [gVisor](https://northflank.com/blog/what-is-gvisor) are also available where supported and appropriate. CPU and GPU sandboxes use this isolation model alongside Northflank services and jobs, so isolated code execution sits within the same platform used to run the rest of the application stack. In BYOC, runtime availability depends on the provider, region, and node-pool configuration. Northflank does not currently offer Windows or macOS Sandboxes. Daytona supports Linux containers, Linux and Windows VMs, GPU Sandboxes, and macOS Sandboxes on Apple silicon. Linux containers use the Sysbox runtime by default, while Kata Containers can be used when microVM isolation is required. ## How do Northflank and Daytona compare on sandbox lifecycle and persistence? Northflank Sandboxes use a service lifecycle built around create, run, scale to zero, and destroy. Sandbox root filesystems are ephemeral by default, while [persistent volumes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#create-sandbox-with-volume-for-persistence) can preserve repositories, datasets, models, and agent state across restarts. Scale-to-zero pauses compute billing while attached volumes are retained, and there is no fixed sandbox session duration. For repeatable environments, [Templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code) and [Workflows](https://northflank.com/docs/v1/application/release/configure-workflows) can reproduce the broader application topology, including services, databases, and multiple Sandboxes rather than just a single sandbox state. Daytona supports sandbox lifecycle controls including stop, archive, delete, automatic lifecycle policies, ephemeral mode, and snapshots for reproducing sandbox state. ## How do Northflank and Daytona compare on templates, startup, and scaling? Northflank Sandboxes boot in under one second and can be created from [Dockerfiles](https://northflank.com/docs/v1/application/build/build-with-a-dockerfile), [Buildpacks](https://northflank.com/docs/v1/application/build/build-with-buildpacks), or external container registries. [Horizontal autoscaling](https://northflank.com/docs/v1/application/scale/autoscale-deployments) can scale workloads based on CPU, memory, requests per second, or Prometheus metrics, while BYOC adds node-pool scaling, spot capacity, and placement controls. In the [ComputeSDK 2026 Scale Invitational](https://platform.computesdk.com/scale-invitational/northflank), Northflank reported creating more than 100,000 concurrent 0.5-CPU Sandboxes from cold start in 24 seconds with zero failures, with P99 allocation of 566ms and P99 readiness of 733ms. Daytona supports sandbox creation from Docker images, with published Linux container creation benchmarks below 90ms, as well as snapshots for reproducing sandbox state. ## How do Northflank and Daytona compare on storage, networking, and GPU support? Northflank combines ephemeral Sandbox roots with persistent volumes, giving teams a choice between disposable execution environments and state that survives restarts. Sandboxes can use private DNS, public or private ports, [multi-project networking](https://northflank.com/docs/v1/application/network/enable-multi-project-networking), and [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies) to control communication between workloads. BYOC also supports [static egress IPs](https://northflank.com/docs/v1/application/bring-your-own-cloud/configure-static-egress-ips). Because Sandboxes run within the same platform as managed databases, services, and jobs, they can connect to PostgreSQL, MySQL, MongoDB, Redis, RabbitMQ, and MinIO through the same private networking layer. Daytona provides per-sandbox volumes with isolation between sandbox mount paths, along with per-sandbox outbound network controls. Its firewall can block outbound traffic, allow specific CIDR ranges, or allow specific domains, while sandbox-to-sandbox networking is disabled by default unless explicitly linked. Inbound access can be exposed through preview URLs or SSH with the appropriate access controls. Both platforms support GPU-backed sandbox workloads. Daytona supports NVIDIA and AMD GPUs. Northflank supports [GPU-backed Sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#create-a-gpu-sandbox), as well as GPU-enabled services and jobs, with hardware including H100, H200, A100, L4, L40S, and B200 across managed cloud and BYOC configurations. ## How do Northflank and Daytona compare on developer experience? Northflank supports the full application workflow from source code to production, with [Git-to-deploy](https://northflank.com/docs/v1/application/getting-started/build-and-deploy-your-code), [Dockerfiles](https://northflank.com/docs/v1/application/build/build-with-a-dockerfile), [Buildpacks](https://northflank.com/docs/v1/application/build/build-with-buildpacks), external registries, [Workflows](https://northflank.com/docs/v1/application/release/configure-workflows), [Templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code), and [GitOps](https://northflank.com/docs/v1/application/infrastructure-as-code/gitops-on-northflank). Teams can manage infrastructure through the [API](https://northflank.com/docs/v1/api/use-the-api), [CLI](https://northflank.com/docs/v1/api/use-the-cli), or SDKs. [Northflank Skills](https://github.com/northflank/skills) extend this workflow to Claude Code, Codex, Cursor, and OpenCode, allowing AI coding agents to deploy and manage workloads through the Northflank API and CLI, subject to credentials, RBAC, and audit controls. Northflank Harnesses provide dedicated cloud coding environments for AI coding agents with isolated resources and networking. Daytona supports SDKs for managing sandbox lifecycles, files, processes, code execution, runtime configuration, and networking. Its REST API and CLI expose the same core functionality. Daytona's production codebase moved to a private repository in June 2026; its previous public repository remains available but is no longer maintained. The difference is primarily in scope: Daytona's tooling is centered on creating and managing programmable sandbox environments, while Northflank combines sandbox management with the tooling needed to build, deploy, automate, and operate the rest of the application stack. ## How do Northflank and Daytona compare on BYOC and infrastructure control? Northflank supports self-service production BYOC, allowing teams to deploy the Northflank data plane into their own cloud account across AWS, GCP, Azure, Oracle, CoreWeave, Civo, and Nebius. The customer retains ownership of the cloud account, VPC, billing relationship, and existing cloud commitments, while Northflank provides the platform control plane and deployment tooling. BYOC can be set up without a sales process or annual contract, while Enterprise agreements can add assisted onboarding and SLAs where required. Daytona also supports customer-managed compute through its Bring Your Own Compute model, where organizations attach their own runner nodes to custom regions managed through Daytona's control plane. Daytona BYOC requires an annual spend commitment, making the commercial model an important difference for teams evaluating customer-managed infrastructure. Northflank also supports environments where the platform itself needs to run inside the customer's infrastructure. Its [forward-deployed control plane](https://northflank.com/enterprise) can run the control plane, API, and audit database within the enterprise environment, which is relevant for regulated, air-gapped, or network-restricted deployments. Northflank therefore provides multiple infrastructure models, from managed Cloud to customer-owned BYOC and forward-deployed environments, while Daytona's infrastructure model centers on its control plane managing customer-provided compute. ## How do Northflank and Daytona compare on security and observability? Northflank provides security controls across both isolated workloads and the platform used to manage them. [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control) applies at the organisation, team, project, and resource levels, while [SAML and OIDC SSO](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication) integrate with identity providers including Okta, Entra ID, and Google Workspace. [Audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) provide organisation-to-resource visibility and can be exported to SIEM systems. Northflank is SOC 2 Type 2 and HIPAA compliant, with Enterprise BAAs, while Enterprise deployments can use [forward-deployed and air-gapped control planes](https://northflank.com/enterprise) for environments with stricter infrastructure requirements. Daytona provides sandbox-level security controls including dedicated namespaces, resource quotas, filesystem restrictions where applicable, configurable outbound network policies, and an ephemeral mode that removes sandbox state when an environment stops. Daytona states that it supports SOC 2 Type 2, GDPR, and HIPAA requirements, with additional security controls available through its Enterprise offering. For observability, Northflank provides logs and metrics across services, jobs, builds, and addons, alongside health checks, alerts, log sinks, and audit logs. Daytona provides telemetry and sandbox-level runtime visibility through its platform and APIs. ## How do Northflank and Daytona compare on pricing? Northflank Cloud charges $0.01667 per vCPU-hour and $0.00833 per GB-hour, billed per second with no seat fees on Pay-as-you-go. The free Sandbox tier includes two services, one database, and two cron jobs with always-on compute. For BYOC, Northflank charges $0.01389 per vCPU-hour and $0.00139 per GB-hour, while the underlying cloud infrastructure is billed directly by the provider. This lets teams use existing cloud credits and committed spend contracts, and BYOC access does not require an annual commitment. Enterprise pricing is custom. Daytona uses usage-based pricing with $200 in free compute and no credit card required to get started. CPU sandboxes are priced at approximately $0.0504 per vCPU-hour, billed per second, with memory and storage charged separately. Daytona's BYOC offering requires an annual spend commitment with enterprise pricing. ### Cost at 200 concurrent sandboxes Assumes 200 continuously running CPU sandboxes, each with 1 vCPU and 4 GB/GiB memory, for 720 hours per month; excludes storage, network, GPU, and other charges. | Deployment model | Monthly modeled cost | | --- | --- | | Northflank | **$7,198.56** | | Daytona | **$16,588.80** | Under these published rates and assumptions, Northflank's modeled CPU and memory cost is approximately 57% lower. ## When should you choose Northflank vs Daytona? | Requirement | Northflank | Daytona | | --- | --- | --- | | **Platform focus** | Sandboxes, Cloud Harnesses, and production application infrastructure in one control plane | Programmable sandbox infrastructure for AI-generated code | | **Isolation** | Kata Containers with Cloud Hypervisor as the primary microVM approach; Firecracker and gVisor where supported | Container and VM-based sandbox environments | | **Cold start** | Under 1 second | Sub-90ms for Linux containers; some configurations reach 27ms | | **GPU** | GPU Sandboxes, services, and jobs with H100, H200, A100, L4, L40S, and B200 on managed cloud and BYOC | NVIDIA and AMD GPU Sandboxes | | **BYOC** | Self-service across AWS, GCP, Azure, Oracle, CoreWeave, Civo, and Nebius; no annual commitment | Available through Bring Your Own Compute; requires an annual commitment | | **Managed databases** | PostgreSQL, MySQL, MongoDB, Redis, RabbitMQ, MinIO | No first-class managed database services | | **Preview environments** | Full-stack Preview Blueprints for applications and supporting infrastructure | No equivalent full-stack preview platform | | **Enterprise governance** | SOC 2 Type 2, HIPAA, granular RBAC, SAML/OIDC SSO, audit logs, forward-deployed and air-gapped options | SOC 2, GDPR, HIPAA, and Enterprise security controls | | **Pricing model** | Per-second Cloud billing with no Pay-as-you-go seat fees; BYOC platform fees plus underlying cloud infrastructure | Usage-based pricing with CPU, memory, storage, and GPU rates | | **Fits teams that need** | Isolated development and production workloads alongside application infrastructure | Programmable sandbox environments for AI-generated code | ## FAQ: Northflank vs Daytona sandboxes ### What is the main difference between Northflank and Daytona? Both platforms provide isolated execution for AI agents and untrusted code. Northflank combines Sandboxes with Cloud Harnesses and the infrastructure used to build and operate applications, while Daytona focuses on programmable sandbox environments. ### Is Northflank a Daytona alternative? Yes. Northflank provides CPU and GPU Sandboxes alongside services, jobs, databases, networking, Templates, Workflows, Preview Environments, and other application infrastructure. ### Does Daytona support BYOC? Yes. Daytona offers Bring Your Own Compute through Enterprise custom regions. Northflank provides self-service BYOC across multiple cloud providers and customer-controlled infrastructure. ### How do Northflank and Daytona handle enterprise security? Northflank provides granular RBAC, SAML and OIDC SSO, audit logs, compliance support, and forward-deployed and air-gapped deployment options. Daytona provides sandbox isolation, network controls, and Enterprise security features. ### Can Daytona run macOS and Windows sandboxes? Yes. Daytona supports macOS sandboxes on Apple silicon and Windows VM sandboxes. Northflank Sandboxes are Linux-based and use microVM-backed isolation.

How to run the Codex AI coding agent securely in the cloud

2026-09-21T17:40:00.000Z

Running Codex securely in the cloud entails setting up an isolated coding workspace and limiting the files, credentials, and network connections the AI coding agent can access. A Codex sandbox adds command-level restrictions as the agent edits code, executes commands, and runs tests in that workspace. This article shows you how to run Codex securely in the cloud with Northflank Cloud Harnesses, from setting up your workspace and configuring access to running your first task. ## TL;DR: How to run Codex securely in the cloud Use Northflank Cloud Harnesses to give Codex a remote workspace with your repository, development tools, and task-specific access. Create and authenticate the workspace first, then prepare your project, review permissions, and run a small task. Check the changes and test results before keeping the work, and pause or delete the workspace when finished. - Create a Cloud Harness, select Codex, and choose its environment. - Authenticate Codex, connect your repository and branch, and review runtime and storage options. - Install dependencies and add the development configuration your tests need. - Review Codex's permissions, run a small task, and inspect the changes and test results. - Add application ports if the task needs a preview. - Use the browser or SSH, monitor resources, and pause with persistent storage enabled or export your work before deletion. [Get started with Northflank Cloud Harnesses](https://app.northflank.com/signup) on a self-serve [Pay As You Go plan](https://northflank.com/pricing) and follow the [Cloud Harness quickstart guide](https://northflank.com/docs/v1/application/cloud-harness/quickstart), or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to see how Cloud Harnesses fit your team's security and infrastructure requirements. ## What is a Codex sandbox? A Codex sandbox restricts which files and network resources Codex's commands can access. It lets the agent work within defined permissions while editing code and running tests. [Codex's approval settings](https://learn.chatgpt.com/docs/sandboxing) separately control when it pauses for authorization before executing an action. When you run Codex in the cloud, the coding workspace holds your repository, tools, and running processes. The command sandbox operates within that environment, alongside the credentials and network controls you configure for the workspace. ## How do you run Codex securely in the cloud? Run Codex in an isolated cloud workspace with your repository, development tools, and only the credentials its task needs. Review its command permissions, control network access, and inspect the resulting code changes before merging them. A cloud workspace gives Codex somewhere to edit files and run tests away from your laptop. Moving execution there changes which files and services it can reach, so keep production credentials and unrelated data outside that workspace. [Northflank](https://northflank.com/) is an AI-agent sandbox and workload platform for running untrusted code in isolated environments on managed infrastructure or in your own cloud. A Cloud Harness brings that infrastructure into an interactive coding workflow: you choose the environment, supply the repository, and work with the agent inside it. In this tutorial, you will create that workspace with [Northflank Cloud Harnesses](https://northflank.com/docs/v1/application/cloud-harness/quickstart). Northflank is the cloud platform that runs the workspace; a Cloud Harness brings together your coding agent, repository, runtime tools, and storage. You can use Northflank-managed infrastructure or your own cloud. ## What do you need to run Codex on Northflank? Before creating your Cloud Harness, have the following ready: - A [Northflank account](https://app.northflank.com/signup) on a **Pay As You Go** plan. - An account with Codex access, or an OpenAI API key, for agent authentication. - A [Git integration](https://northflank.com/docs/v1/application/getting-started/link-your-git-account) if you want to connect an existing repository. To follow along, choose an existing repository with a test suite and a development branch. Start with a small task, such as fixing a failing unit test. Connecting a repository is optional when creating a Cloud Harness, but you’ll need one to follow this example. ## How do you create a Cloud Harness for Codex? Create the workspace in the Northflank dashboard using the [Cloud Harness creation flow](https://northflank.com/docs/v1/application/cloud-harness/quickstart). 1. **Create or open a project.** A project groups related resources. To [create a project](https://northflank.com/docs/v1/application/getting-started/create-a-project), select **Create project** from your team dashboard, enter a name, select the region for your chosen infrastructure, and select **Create project** again. Open **Harnesses** in the project. 2. **Select Codex** as the coding agent. 3. **Name the Cloud Harness**, for example `codex-test-fix`. 4. **Select the environment** where it should run. 5. **Choose authentication.** Under **Authentication**, select an API key or linked account. 6. **Choose a repository.** Under **Repository**, select an existing repository and branch, create a repository, or continue without one. 7. **Review Advanced options if needed.** Configure runtime variables, the runtime image, resources, and workspace storage. The runtime image supplies the operating environment and installed tools. 8. **Select Create Harness.** Northflank opens the terminal. Complete the agent sign-in if prompted. ![codex-harness.webp](https://assets.northflank.com/codex_harness_45ada44f09.webp) Your Cloud Harness is now created. The following sections cover preparing your project, working with Codex, and managing the workspace after setup. ## How do you prepare your project for Codex? Prepare the project inside your Cloud Harness by installing dependencies, adding development configuration, and running the existing tests. Follow the repository's setup instructions, and configure any services and credentials the tests require before running them. Read installation scripts first, especially in an unfamiliar repository. They execute code with access to credentials available in their environment. In the Northflank dashboard, open the Cloud Harness and select the **Environment variables** icon in the right sidebar, then click **Edit**. Add the runtime variables or secret files your application needs and select **Update & restart**. These [Cloud Harness settings](https://northflank.com/docs/v1/application/cloud-harness/configure-and-manage-cloud-harnesses) supply configuration to code running in the workspace. ![codex-environment.png](https://assets.northflank.com/codex_environment_5f95a4a451.png) Use development credentials with access limited to the task. Keep production credentials outside the workspace, and avoid scripts that save secrets in logs or generated files. Run the project's existing tests in the Cloud Harness's shell, from the repository directory, and keep the results as your starting point. ## Which Codex controls should you check before running a task? Review the active [Codex sandbox and approval settings](https://learn.chatgpt.com/docs/sandboxing) inside your Cloud Harness before asking the agent to work. In a Codex CLI session, enter `/permissions` to open the permissions picker. Choose permissions appropriate to the task and keep approval requests directed to you when you want to review broader access. The Cloud Harness provides the workspace; Codex's command sandbox separately restricts file and network access. Check the active session rather than assuming the workspace enables a particular Codex policy. On Linux, check sandbox startup warnings and the [bubblewrap and user-namespace prerequisites](https://learn.chatgpt.com/docs/sandboxing#prerequisites) before relying on command sandboxing. Project instructions and prompts guide Codex's behaviour. They do not enforce access restrictions. Also review any connected [web, app, or MCP tools](https://learn.chatgpt.com/docs/agent-approvals-security#traffic-outside-the-command-network-proxy), which use access controls separate from the command sandbox. ## How do you run and review a Codex task? Open the Codex session inside your Northflank Cloud Harness and give it a small task with a clear stopping point. Adapt this prompt to a failing test in your repository: ``` Read the project instructions and identify the relevant test command. Investigate the failing test described below. Explain the cause and propose the smallest relevant fix before editing files. Do not change unrelated files or add dependencies without asking. Failing test: ``` Review the proposed approach, then ask Codex to implement the agreed change and run the affected tests. Ask it to show the command used and any failures that remain. Review requests for broader access before approving them. In the Cloud Harness's shell, run these commands from the repository directory to inspect the changes: ```bash git status --short --untracked-files=all git diff --stat git diff git diff --cached ``` The [status command](https://git-scm.com/docs/git-status) lists changed and untracked files. The [diff commands](https://git-scm.com/docs/git-diff) show a summary, unstaged changes, and staged changes. Open untracked files separately because they do not appear in `git diff`. Run the affected tests yourself and compare the result with the original failure. Check for unrelated changes, unnecessary dependencies, and accidentally included secrets. If a command fails because a tool or service is missing, correct the development configuration before expanding access. Complete any application preview checks the task needs, then commit and push the reviewed changes through your normal pull-request process. Keep the task, starting commit, patch, and test results together in your [AI-agent execution audit trail](https://northflank.com/blog/ai-agent-code-execution-audit-trail). ## How do you preview an application built with Codex? To preview an application, ask Codex to start its development server inside the Cloud Harness and identify the listening port. In the Northflank dashboard, open the Cloud Harness overview and select the **Networking** icon in the right sidebar: 1. Select **Add port**. 2. Enter the application's port and select its protocol. 3. Enable **Publicly expose** only if people need to access the preview from the internet. 4. Select **Save changes**. The [networking controls](https://northflank.com/docs/v1/application/cloud-harness/configure-and-manage-cloud-harnesses) support private and public ports, with domains for publicly exposed ports. For a web preview, [bind the application to `0.0.0.0`](https://northflank.com/docs/v1/application/network/expose-your-application) so Northflank can route traffic to it. ![codex-port.png](https://assets.northflank.com/codex_port_9a038e422b.png) Before sharing a public preview, check for sensitive data, debug routes, and missing authentication. Remove public access when it is no longer needed. Port exposure controls incoming connections. For outbound restrictions on your own cluster, configure [BYOC network policies](https://northflank.com/docs/v1/application/network/configure-network-policies); without egress rules, outbound traffic is allowed. ## How do you access your Codex workspace through SSH? You can use Northflank's SSH access to work in the Cloud Harness from your local terminal, or continue using the browser terminal. Install and authenticate the [Northflank command-line interface (CLI)](https://northflank.com/docs/v1/api/use-the-cli). To [connect to your Cloud Harness locally](https://northflank.com/docs/v1/application/cloud-harness/quickstart#connect-to-your-cloud-harness-locally), open its overview in the Northflank dashboard, select **Connect** under **Local access**, and copy the generated command. Run it in your local terminal. It has this form: ```bash northflank dev ssh --projectId YOUR_PROJECT_ID --harnessId YOUR_HARNESS_ID ``` Use the generated command, or replace both placeholders with your project and Cloud Harness IDs. This [SSH connection](https://northflank.com/docs/v1/application/cloud-harness/quickstart) opens access to the existing cloud workspace. ## How do you monitor CPU and memory usage in your Codex workspace? Northflank shows CPU and memory usage for the Cloud Harness and its running processes. Check these metrics while installing dependencies or running a demanding test suite to see whether workspace resources may be contributing to slow performance. To [monitor the workspace](https://northflank.com/docs/v1/application/cloud-harness/configure-and-manage-cloud-harnesses#monitor-cloud-harness-resources), open its overview in the Northflank dashboard and select the **Observe** icon in the right sidebar. If the project needs more resources, select **Settings**, adjust the resource configuration, and select **Update options**. Rerun the task and check its behaviour and resource usage again. ![codex-monitor-harness.png](https://assets.northflank.com/codex_monitor_harness_d3d4678bf4.png) ## How do you pause or delete your Codex cloud workspace? In Northflank, pause the Cloud Harness to return to the work later, or delete it after saving the files you need. An active Cloud Harness keeps running until you pause or delete it; closing your terminal does not stop it. To [pause your Cloud Harness](https://northflank.com/docs/v1/application/cloud-harness/configure-and-manage-cloud-harnesses#pause-and-resume-a-cloud-harness), open its overview and select the **Pause harness** icon in the top-right corner. With persistent workspace storage enabled, files under `/home/harness` survive, while terminal sessions and running processes stop. Select **Resume harness** from the overview when you want to continue, then restart any development servers or other processes you need. Persistent storage defaults to enabled at creation. If you disabled it, files are lost when the container restarts, is redeployed, or stops. Before deleting, push your commits or export the files you want to keep. Open the three-dot menu in the top-right corner, select **Delete harness**, and confirm. [Deleting a Cloud Harness](https://northflank.com/docs/v1/application/cloud-harness/configure-and-manage-cloud-harnesses#delete-a-cloud-harness) permanently removes its associated workspace. Revoke temporary credentials at the services that issued them when they are no longer needed. ## Start your next Codex task in a Cloud Harness You now have a workflow for creating a Codex workspace, giving it the access a task needs, reviewing its changes, and deciding what to retain. Start with one repository and one small fix, then reuse that process as your team takes on larger tasks. [Get started with Northflank](https://app.northflank.com/signup), or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss running Cloud Harnesses in your own cloud. ## Frequently asked questions about Codex in Cloud Harnesses ### Is a Cloud Harness the same as Codex's command sandbox? A Cloud Harness is the cloud workspace where Codex runs. Codex's command sandbox restricts which files and network resources its commands can access. Review the session's permissions alongside the workspace's credentials and network access. ### Can teammates work in the same Codex workspace? Yes. Multiple team members can work in the same Cloud Harness simultaneously. Share access with collaborators authorised to use the same repository, development data, and credentials. ### Can I run Codex in my own cloud account? Yes. You can run Codex in a Northflank Cloud Harness on Northflank-managed infrastructure or in your own cloud account. [Northflank BYOC](https://northflank.com/docs/v1/application/bring-your-own-cloud/use-other-cloud-providers-with-northflank) creates and manages Kubernetes clusters in your cloud account, where your cloud provider bills you for the resources. ### Can I keep workspace files between Codex sessions? Yes. With persistent workspace storage enabled, files under `/home/harness` survive pause and resume. Running processes and terminal sessions stop when paused. Export the files you need before deleting the Cloud Harness. ## Related articles about secure AI-agent execution - [What infrastructure do AI agents need to run code safely?](https://northflank.com/blog/ai-agent-code-execution-infrastructure) - [What should an audit trail for AI-agent code execution contain?](https://northflank.com/blog/ai-agent-code-execution-audit-trail) - [AI-agent sandbox security checklist](https://northflank.com/blog/ai-agent-sandbox-security-checklist) - [How to give your AI agent a secure computer](https://northflank.com/blog/give-ai-agent-secure-computer)

How to run the Claude Code AI coding agent securely in the cloud

2026-09-21T17:38:00.000Z

Running Claude Code securely in the cloud means giving it an isolated workspace and limiting access to files, credentials, and network connections. Claude Code is an AI coding agent that can edit files, run commands, and test changes. When enabled on a supported platform, Claude Code’s built-in Bash sandbox adds filesystem and network restrictions for sandboxed shell commands and their child processes. This article shows you how to run Claude Code securely in the cloud with Northflank Cloud Harnesses, from setting up your workspace and configuring access to running your first task. ## TL;DR: How to run Claude Code securely in the cloud Use Northflank Cloud Harnesses to give Claude Code a remote workspace with your repository, development tools, and task-specific access. Create and authenticate the workspace first, then prepare your project, review permissions, and run a small task. Check the changes and test results before keeping the work, and pause or delete the workspace when finished. - Create a Cloud Harness, select Claude, and choose where the workspace runs. - Authenticate Claude, connect your repository and branch, and configure the runtime and storage. - Install the project dependencies and add only the development credentials it needs. - Review Claude Code's permissions, use Plan mode, then run your first task and inspect the changes and test results. - Configure application ports if needed, keeping public access limited to what you intend to expose. - Work through the browser or connect by SSH, monitor the workspace, then pause with persistent storage enabled or export your work and delete it. [Get started with Northflank Cloud Harnesses](https://app.northflank.com/signup) on a self-serve [Pay As You Go plan](https://northflank.com/pricing) and follow the [Cloud Harness quickstart guide](https://northflank.com/docs/v1/application/cloud-harness/quickstart), or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to see how Cloud Harnesses fit your team’s security and infrastructure requirements. ## What is a Claude Code sandbox? A Claude Code sandbox is an environment that restricts what the agent can access while it edits files, runs commands, and tests changes. A cloud sandbox lets you run that work remotely, with a workspace and credentials configured for the project. Claude Code also includes a [built-in Bash sandbox](https://code.claude.com/docs/en/sandboxing) that restricts shell commands and their child processes. A cloud workspace and this command-level sandbox provide different controls; check each separately when configuring access. ## How do you run Claude Code securely in the cloud? Run Claude Code in an isolated cloud workspace with your repository, development tools, and only the credentials its task needs. Review its command permissions, control network access, and inspect the resulting code changes before merging them. A cloud workspace gives Claude Code somewhere to edit files and run tests away from your laptop. Moving execution there changes which files and services it can reach, so keep production credentials and unrelated data outside that workspace. [Northflank](https://northflank.com/) is an AI-agent sandbox and workload platform for running untrusted code in isolated environments on managed infrastructure or in your own cloud. A Cloud Harness brings that infrastructure into an interactive coding workflow: you choose the environment, supply the repository, and work with the agent inside it. In this tutorial, you will create that workspace with [Northflank Cloud Harnesses](https://northflank.com/docs/v1/application/cloud-harness/quickstart). Northflank is the cloud platform that runs the workspace; a Cloud Harness brings together your coding agent, repository, runtime tools, and storage. You can use Northflank-managed infrastructure or your own cloud. ## What do you need to run Claude Code on Northflank? Before creating your Cloud Harness, have the following ready: - A [Northflank account](https://app.northflank.com/signup) on a **Pay As You Go** plan. - A Claude account with Claude Code access, or an Anthropic API key, for agent authentication. - A [Git integration](https://northflank.com/docs/v1/application/getting-started/link-your-git-account) if you want to connect an existing repository. For this walkthrough, use a repository with a test suite, a development branch, and a small task such as fixing a login-form validation error. You can also create a new repository or continue without one during setup. ## How do you create a Cloud Harness for Claude Code? Create the workspace from the Northflank dashboard using the [Cloud Harness quickstart](https://northflank.com/docs/v1/application/cloud-harness/quickstart). 1. **Create or open a project.** A project groups related resources. To [create a project](https://northflank.com/docs/v1/application/getting-started/create-a-project), select **Create project**, enter a name, choose **Northflank Cloud** or **Bring Your Own Cloud** under **Deployment target**, select a region, and create the project. Then open **Harnesses**. 2. **Select Claude** as the coding agent. 3. **Name the Cloud Harness**, for example `claude-login-fix`. 4. **Select the environment** where it should run. 5. **Choose authentication.** Under **Authentication**, select an API key or a linked account. 6. **Choose a repository.** Under **Repository**, select an existing repository and branch, create a new repository, or continue without one. 7. **Review Advanced options if needed.** You can configure runtime variables, the runtime image, resources, and workspace storage. 8. **Select Create Harness.** Northflank opens the terminal. Complete the agent sign-in if prompted. ![claude-code-create.png](https://assets.northflank.com/claude_code_create_eb75a1e0aa.png) The workspace is now ready for you to use Claude Code. The sections below cover working on a task and managing access and workspace lifetime after setup. ## How do you prepare your project for Claude Code? Prepare the project inside your Cloud Harness by installing its dependencies, adding any required development configuration, and running its existing tests. Follow your repository's setup instructions, and configure the services and credentials the tests require before running them. Read installation scripts before running them, especially in an unfamiliar repository. They execute code with access to the credentials available in their environment. Open **Environment variables** in the workspace's right sidebar and select **Edit**. Add the runtime variables or secret files your application requires, then select **Update & restart** to apply them. These controls are part of [Cloud Harness configuration](https://northflank.com/docs/v1/application/cloud-harness/configure-and-manage-cloud-harnesses). ![env-harness.webp](https://assets.northflank.com/env_harness_8f4824618e.webp) Add only the development credentials your project needs. Before asking Claude to change code, run the project’s existing tests and keep the results so you can identify any new failures. ## Which Claude Code controls should you check before running a task? Inside your Cloud Harness, review [Claude Code’s permission settings](https://code.claude.com/docs/en/permissions) before giving it a task. Keep approval checks enabled for actions that need your review, and use [Plan mode](https://code.claude.com/docs/en/permissions#permission-modes) to inspect Claude’s proposed approach before allowing edits. If you want to use Claude Code's additional Bash sandbox, run `/sandbox` inside Claude Code to check its availability and status. Enable it if you intend to rely on it, review its filesystem and network settings, and test a project command inside it. On Linux, confirm that `bubblewrap` and `socat` are installed and that the runtime supports sandboxing. Review unsandboxed fallback settings before treating it as an enforced boundary. See the [Bash sandbox setup](https://code.claude.com/docs/en/sandboxing) for configuration details. ## How do you run and review a Claude Code task? In your Northflank Cloud Harness, open the Claude Code session and give it a task with a clear stopping point. Adapt this prompt to the validation error in your repository: ``` Read the project instructions and identify the relevant test command. Find the login form and investigate the validation error described below. Explain the cause and propose the smallest relevant fix before editing files. Do not change unrelated files or add dependencies without asking. Validation error: ``` Check the proposed files and approach. Then switch to an editing mode and ask Claude to implement the agreed change, add or update the relevant test, and run it. Ask it to show the command used and any failures that remain. In the Cloud Harness’s shell, run these commands from the repository directory to inspect the changes: ```bash git status --short --untracked-files=all git diff --stat git diff git diff --cached ``` The [status command](https://git-scm.com/docs/git-status) lists changed and untracked files. The [diff commands](https://git-scm.com/docs/git-diff) show a summary, unstaged changes, and staged changes. Open untracked files separately; they do not appear in `git diff`. Run the relevant tests yourself and compare the result with the starting failure. Check that the change stays within the task, that dependency changes are necessary, and that no secrets or unrelated files have been added. A passing test helps validate the fix, but it does not replace reviewing the code. If a command fails because a tool or service is missing, correct the runtime or development configuration and rerun it. Expand access only when you understand why the task needs it. Complete any application preview checks needed for the task, then commit and push the reviewed changes through your normal pull-request process. Keep the task, starting commit, patch, and test results together so a reviewer can trace the work. Your [AI-agent execution audit trail](https://northflank.com/blog/ai-agent-code-execution-audit-trail) should connect that evidence to any later release. ## How do you preview an application built with Claude Code? To preview the application through Northflank, ask Claude Code to start the development server inside your Cloud Harness and identify its listening port. In the Northflank dashboard, open your Cloud Harness and select the **Networking** icon in the right sidebar: 1. Select **Add port**. 2. Enter the application's port and select the protocol. 3. Enable **Publicly expose** only if the preview needs internet access. 4. Select **Save changes**. ![configure-harness.webp](https://assets.northflank.com/configure_harness_3ec76a2316.webp) The [networking controls](https://northflank.com/docs/v1/application/cloud-harness/configure-and-manage-cloud-harnesses) support private and public ports, with domains for publicly exposed ports. For a web preview, [bind the application to `0.0.0.0`](https://northflank.com/docs/v1/application/network/expose-your-application) so Northflank can route traffic to its listening port. Before sharing a public preview, check for debug routes, sensitive data, and missing authentication. Remove public access when the review is complete. Port exposure controls incoming connections. If you also need outbound restrictions on your own cluster, configure [BYOC network policies](https://northflank.com/docs/v1/application/network/configure-network-policies); without egress rules, outbound traffic is allowed. ## How do you access your Claude Code workspace through SSH? You can use Northflank’s SSH access to connect to your Cloud Harness from your local terminal while Claude Code runs in the cloud, or continue working in the browser terminal. Install and authenticate the [Northflank command-line interface (CLI)](https://northflank.com/docs/v1/api/use-the-cli). To [connect to your Cloud Harness locally](https://northflank.com/docs/v1/application/cloud-harness/quickstart#connect-to-your-cloud-harness-locally), open its overview in the Northflank dashboard, select **Connect** under **Local access**, and copy the generated command. Run it in your local terminal. It has this form: ```bash northflank dev ssh --projectId YOUR_PROJECT_ID --harnessId YOUR_HARNESS_ID ``` Use the dashboard-generated command, or replace both placeholders with your project and Cloud Harness IDs. This [SSH connection](https://northflank.com/docs/v1/application/cloud-harness/quickstart) gives you access to the existing workspace. ![connect-harness.webp](https://assets.northflank.com/connect_harness_b315d1b7bc.webp) ## How do you monitor CPU and memory usage in your Claude Code workspace? You can use Northflank to see how much CPU and memory your Cloud Harness uses while Claude Code runs project commands, installs dependencies, or executes tests. These metrics show resource usage for the workspace, including the processes running inside it. To [monitor your Cloud Harness](https://northflank.com/docs/v1/application/cloud-harness/configure-and-manage-cloud-harnesses#monitor-cloud-harness-resources), open its overview in the Northflank dashboard and select the **Observe** icon in the right sidebar. Check CPU and memory usage while the slow or demanding task runs to understand whether resource limits may be contributing to the problem. ![monitor-harness.webp](https://assets.northflank.com/monitor_harness_b5bf77c9ab.webp) If the project needs more resources, select the **Settings** icon, adjust the resource configuration, and select **Update options**. Follow the [Cloud Harness configuration instructions](https://northflank.com/docs/v1/application/cloud-harness/configure-and-manage-cloud-harnesses), then rerun the task and check its behaviour and resource usage again. ## How do you pause or delete your Claude Code cloud workspace? In Northflank, pause the Cloud Harness to return to the work later, or delete it after saving the files you need. An active Cloud Harness keeps running until you pause or delete it; closing your terminal does not stop it. To [pause your Cloud Harness](https://northflank.com/docs/v1/application/cloud-harness/configure-and-manage-cloud-harnesses#pause-and-resume-a-cloud-harness), open its overview and select the **Pause harness** icon in the top-right corner. With persistent workspace storage enabled, files under `/home/harness` survive, while terminal sessions and running processes stop. Select **Resume harness** from the overview when you want to continue, then restart any development servers or other processes you need. Persistent storage defaults to enabled at creation. If you disabled it, files are lost when the container restarts, is redeployed, or stops. Before deleting, push your commits or export the files you want to keep. Open the three-dot menu in the top-right corner, select **Delete harness**, and confirm. [Deleting a Cloud Harness](https://northflank.com/docs/v1/application/cloud-harness/configure-and-manage-cloud-harnesses#delete-a-cloud-harness) permanently removes its associated workspace. Revoke temporary credentials at the services that issued them when they are no longer needed. ## Give Claude a workspace for your next development task Create a Cloud Harness, connect a development branch, and let Claude work on one change you can test and review. Once that workflow works for your project, reuse the environment with clear access and cleanup rules. [Get started with Northflank](https://app.northflank.com/signup), or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your team's infrastructure and security requirements. ## Frequently asked questions about Claude Code in Cloud Harnesses ### Is a Cloud Harness the same as Claude Code's built-in sandbox? A Cloud Harness provides the cloud workspace where Claude Code runs. Claude Code's [built-in Bash sandbox](https://code.claude.com/docs/en/sandboxing) separately restricts shell commands and their child processes. Check its status with `/sandbox` inside Claude Code; workspace configuration and command sandboxing are separate controls. ### Can I access the Claude Code workspace through SSH? Yes. Use **Local access → Connect** to copy the SSH command, then run it with the Northflank CLI installed and authenticated. Claude Code continues working in the remote environment. ### Can teammates work in the same workspace? Yes. Multiple team members can work in the same Northflank Cloud Harness simultaneously. Share access with collaborators authorised to use the repository and development credentials. ### Can I run Claude Code in my own cloud? Yes. You can run Claude Code in your own cloud account using Northflank Cloud Harnesses with [Northflank BYOC](https://northflank.com/docs/v1/application/bring-your-own-cloud/use-other-cloud-providers-with-northflank). Northflank provisions and manages the Kubernetes cluster, while your team owns the cloud account and underlying resources. ### Can I keep workspace files between Claude Code sessions? Yes. You can keep files between Claude Code sessions in a Northflank Cloud Harness with persistent workspace storage enabled. Files under `/home/harness` survive pause and resume, but terminal sessions and processes stop. Restart the processes you need after resuming, and export any files you want to keep before deleting the Cloud Harness. ## Related articles about secure agent development Continue with the infrastructure and release controls around your coding workspace: - [What infrastructure do AI agents need to run code safely?](https://northflank.com/blog/ai-agent-code-execution-infrastructure) - [What should an audit trail for AI-agent code execution contain?](https://northflank.com/blog/ai-agent-code-execution-audit-trail) - [AI-agent sandbox security checklist](https://northflank.com/blog/ai-agent-sandbox-security-checklist) - [How to deploy an AI agent from sandbox to production](https://northflank.com/blog/how-to-deploy-ai-agent-from-sandbox-to-production)

Best sandbox runners for AI agents and code execution in 2026

2026-09-21T15:45:00.000Z

## TL;DR: Best sandbox runners in 2026 Sandbox runners provide isolated environments for AI agents, user-submitted code, and untrusted scripts. The best choice depends on startup speed, concurrent capacity, isolation, and what needs to persist between tasks. 1. **Northflank: Best for AI agent sandbox execution at high concurrency.** A fit for teams that want fast, isolated sandboxes for AI-generated code, with thousands of concurrent sessions and custom environments for coding agents, APIs, scripts, and GPU tasks. 2. **E2B: Best for agent execution workflows with reusable state.** A fit for teams that need SDK-based execution, pause and resume, and saved workspace state between tasks. 3. **Modal: Best for programmatic sandbox execution with GPUs.** A fit for teams configuring custom environments for code execution and compute-intensive agent tasks. 4. **Fly.io Sprites: Best for persistent agent workspaces.** A fit for teams that want installed tools and project files to survive inactivity, with filesystem checkpoints for rollback. 5. **Vercel Sandbox: Best for sandbox execution in Vercel applications.** A fit for teams that want SDK-managed microVMs, configurable sessions, and snapshots within their existing Vercel workflow. 6. **Cloudflare Sandbox: Best for sandbox execution from Workers.** A fit for teams building agents with Cloudflare Workers that need command execution, file operations, and application previews. 7. **CodeSandbox: Best for cloned environments and parallel agent tasks.** A fit for teams that want reusable development environments with snapshots, cloning, and hibernation. Follow the [Northflank sandbox quickstart](https://northflank.com/docs/v1/application/sandboxes/quickstart) to run your first task, [get started on Northflank](https://app.northflank.com/signup), or [talk to an engineer](https://cal.com/team/northflank/northflank-demo) about your sandbox workload. Sandbox runners cover a wider range of tools than most comparisons acknowledge, from browser-based execution environments to production-grade microVM platforms running at scale. This article compares the best sandbox runners in 2026 across isolation model, persistence, bring your own cloud (BYOC) support, GPU access, startup speed, and concurrency, so you can match the right one to your use case. ## What is a sandbox runner? A sandbox runner is an isolated execution environment that limits what running code can access on your host system, in other tenants, or in production infrastructure. The isolation boundary determines the security model: standard Linux containers share the host kernel and rely on namespace separation, while microVMs and VM-based runtimes such as Firecracker and Kata Containers give each workload a dedicated kernel, and gVisor intercepts system calls in user space to reduce the kernel attack surface. Sandbox runners are used for AI agent code execution, user-submitted scripts, code interpretation, and any workload where you cannot trust the code being run. See [what is a sandbox environment?](https://northflank.com/blog/what-is-a-sandbox-environment) and [what is an AI sandbox?](https://northflank.com/blog/what-is-an-ai-sandbox) for deeper breakdowns. ## What should you look for in a sandbox runner? The evaluation criteria depend on your workload, but these questions are worth working through before committing to a platform: - **What isolation model does it use?** Containers, gVisor, and microVMs offer meaningfully different security guarantees. For untrusted code at scale, microVM-level isolation provides a dedicated kernel per workload. See [Kata Containers vs Firecracker vs gVisor](https://northflank.com/blog/kata-containers-vs-firecracker-vs-gvisor) for a technical breakdown. - **Does it support both ephemeral and persistent environments?** Ephemeral environments handle stateless, short-lived execution. Persistent environments let agents maintain state across sessions without rebuilding from scratch. Check whether persistence includes files, process memory, or both. - **Can it deploy inside your own infrastructure?** If workloads cannot leave your network for compliance or data residency reasons, check whether bring your own cloud (BYOC) is available self-serve or only on an enterprise plan requiring a sales process. - **How quickly can it run your workload at scale?** Check sandbox startup time, concurrency limits, and creation-rate limits. Confirm that custom environments can run your coding agents, scripts, generated APIs, and test suites. - **Does it support GPU workloads?** Not all sandbox runners include GPU access. Confirm this is available within the same platform if your workloads require it. - **Does it meet your compliance requirements?** Check SOC 2 reports, data handling, and any contractual requirements for regulated workloads. ## What are the best sandbox runners in 2026? Each platform below takes a different approach to sandbox execution. Here is what they provide and where they fit. ### 1. Northflank: Best for AI agent sandbox execution at high concurrency [Northflank](https://northflank.com/product/sandboxes) provides isolated sandbox environments for AI agents and code execution, with fast startup and support for thousands of concurrent sessions. Run coding agents, scripts, generated APIs, repository builds, and GPU tasks in custom environments, with persistent files when work needs to continue across sessions. ![northflank-sandbox-page.png](https://assets.northflank.com/northflank_sandbox_page_dd9fa07375.png) **Key capabilities:** - **Fast startup and high concurrency:** Sub-second sandbox boot times on Northflank Cloud, with support for thousands of concurrent sessions. - **Workload isolation:** Managed CPU sandboxes use microVMs, while GPU sandboxes use gVisor. On your own infrastructure, supported runtime options include Kata Containers, Firecracker, and gVisor, depending on the deployment. - **Ephemeral and persistent environments:** Run short-lived tasks or retain files on attached volumes, with no fixed session time limit. - **Custom environments:** Use container images with the languages, dependencies, and tools your agent needs to execute code, test an API, or run a build. - **Deployment options:** Use Northflank's managed cloud or self-serve [bring your own cloud (BYOC)](https://northflank.com/product/bring-your-own-cloud). Northflank acts as the control plane to run coding agents and their sandboxes in your virtual private cloud (VPC), with a supported isolation runtime configured in your cluster. - **GPU execution:** Run GPU tasks in sandboxes with on-demand NVIDIA H100, A100, L4, and other GPU options. - **Programmatic control:** Create sandboxes, execute commands, manage files, and clean up environments through APIs and SDKs. - **Multi-tenancy:** Create separate execution environments for users, agents, or jobs. - **Security:** Northflank is [SOC 2 Type II and HIPAA compliant](https://northflank.com/security), with Business Associate Agreements (BAAs) supported under Enterprise contracts. **Pricing:** $0.01667/vCPU-hour, $0.00833/GB-hour, with H100 GPU plans at $2.74/hour all-inclusive (CPU and RAM included). The free developer Sandbox tier includes always-on compute with no sleeping, two free services, one database, and two cron jobs for development and testing. Pay-as-you-go offers self-service CPU and GPU workloads, per-second billing, no seat-based fees, and autoscaling. Enterprise plans offer custom pricing, volume discounts, 24/7 support, service-level agreements (SLAs), single sign-on (SSO), and audit logs. [See the full pricing details](https://northflank.com/pricing) for additional GPU options and compute plans. Northflank is a strong fit when you need fast sandbox execution, thousands of concurrent agent sessions, custom environments, and persistent files for long-running work. **Next steps:** - [Get started with Northflank](https://app.northflank.com/signup) - [Northflank Sandboxes](https://northflank.com/product/sandboxes) - [Hands-on guide: spin up a secure sandbox and microVM in seconds](https://northflank.com/blog/how-to-spin-up-a-secure-code-sandbox-and-microvm-in-seconds-with-northflank-firecracker-gvisor-kata-clh) - [Book a demo with a Northflank engineer](https://cal.com/team/northflank/northflank-demo) ### 2. E2B E2B supports AI-generated code execution through Python and JavaScript SDKs, with pause and resume for reusable agent workspaces. **Key capabilities:** - **Isolation:** Isolated Linux VMs created on demand via API - **Pause and resume:** Normal pause preserves filesystem and memory; filesystem-only pause keeps files but reboots on resume - **Retention:** Paused sandboxes retained indefinitely with no automatic deletion - **Session limits:** 24 hours on Pro and 1 hour on Hobby, with longer Enterprise options - **Automatic resume:** AutoResume for automatically resuming paused sandboxes when configured - **Snapshots:** Snapshots for saving and restoring sandbox state - **Execution access:** Command execution, interactive terminals, and access to services running inside the sandbox - **Integrations:** Git integration and cloud storage bucket connectivity - **Deployment:** Bring your own cloud (BYOC) available on Enterprise for AWS, GCP, and Azure (requires contacting sales) ### 3. Modal Modal is a serverless compute platform with a sandbox interface for executing untrusted or dynamically defined code. **Key capabilities:** - **Isolation:** gVisor-based sandbox isolation, with CPU-only VM Sandboxes also available in beta - **Custom environments:** Sandbox environments defined and spawned at runtime with custom container images - **Session limits:** Sandbox timeouts configurable up to 24 hours, with Filesystem Snapshots for longer workflows - **GPU execution:** GPU access configurable per sandbox - **Networking:** Tunnels for direct external connections and granular egress network policies - **Persistence:** Filesystem snapshots for state preservation and restoration - **SDKs:** Python SDK (primary), JavaScript and Go SDKs - **Deployment:** No bring your own cloud (BYOC) deployment option ### 4. Fly.io Sprites Sprites are persistent, hardware-isolated Linux environments built on Fly.io's infrastructure. **Key capabilities:** - **Isolation:** Firecracker microVM isolation per Sprite - **Persistent storage:** Persistent 100 GB filesystem with a local cache backed by durable object storage - **Idle billing:** Automatic idle behaviour: compute charges stop when idle, filesystem is preserved - **Idle states:** Warm and cold idle states preserve files; running processes and memory are not preserved - **Checkpoints:** Copy-on-write filesystem checkpoints for restoring disk state without capturing process memory - **Application access:** Unique HTTPS URL per Sprite for exposing services or APIs - **SDKs:** CLI plus JavaScript, Go, and Python SDKs - **Deployment:** No bring your own cloud (BYOC) ### 5. Vercel Sandbox Vercel Sandbox provides on-demand, isolated microVM environments for running untrusted code, tightly integrated with Vercel's deployment infrastructure. **Key capabilities:** - **Isolation:** Firecracker microVM isolation - **Custom environments:** Managed Linux images and custom container images for your runtime and dependencies - **Session limits:** 5 minutes default, up to 45 minutes on Hobby, up to 24 hours on Pro and Enterprise - **Persistence:** Filesystem snapshots and persistent drives for retaining data between sessions - **Resources:** Up to 8 vCPUs and 16GB RAM on Pro, up to 32 vCPUs and 64GB RAM on Enterprise (2GB RAM per vCPU) - **Billing:** Active CPU billing, with provisioned memory, storage, and other usage metered separately - **SDKs:** TypeScript and Python SDKs, CLI - **Deployment:** Runs on Vercel's infrastructure only, no bring your own cloud (BYOC) ### 6. Cloudflare Sandbox Cloudflare Sandbox provides isolated Linux container environments for running untrusted code, built on Cloudflare Containers and Durable Objects. It is available on the Workers Paid plan, with a Sandbox SDK 1.0 preview alongside the stable SDK. **Key capabilities:** - **Isolation:** Isolated Linux containers, with each sandbox running in its own VM - **Lifecycle:** State is maintained while the container is active; state resets after inactivity (10 minutes by default, configurable) - **Code interpreter:** Python and Node.js code interpreter with persistent execution contexts while active - **Nested containers:** Docker-in-Docker support - **Application previews:** Preview URLs via automatic subdomain routing - **Streaming:** WebSocket support for real-time streaming - **Terminal access:** Browser terminal access - **Persistence:** S3-compatible object storage mounting (R2, S3, GCS) for persistence across sessions - **SDK:** TypeScript SDK - **Integrations:** Integrates with Cloudflare Workers, R2, KV, and Workers AI - **Deployment:** No bring your own cloud (BYOC) ### 7. CodeSandbox CodeSandbox, now part of Together AI, provides microVM-based sandbox environments for AI agents, code interpretation, and developer workflows. **Key capabilities:** - **Isolation:** MicroVM infrastructure with snapshot and restore - **Reusable environments:** VM snapshots and cloning for reusable environments - **Persistence:** Sandbox state persistence across sessions via snapshots - **Hibernation:** Customisable hibernation periods - **SDK:** CodeSandbox SDK for programmatic sandbox management - **Workloads:** Supports AI agents, development environments, code interpretation, and CI/CD - **Deployment:** No bring your own cloud (BYOC) ## Which sandbox runner fits your use case? The right platform depends on your primary requirement. Use the table below to narrow down your options. | If you need... | Consider... | | --- | --- | | VM-isolated sandboxes for AI agents with self-serve bring your own cloud (BYOC) | Northflank | | Ephemeral and persistent AI agent sandboxes with no fixed session time limit | Northflank | | Fast sandbox execution for AI-generated code and agent workloads at high concurrency | Northflank | | On-demand GPU execution in sandboxes for AI workloads | Northflank, Modal | | AI sandbox execution on a SOC 2 Type II compliant platform with self-serve bring your own cloud (BYOC) | Northflank | | API-driven sandbox execution with pause, resume, and AutoResume | E2B | | gVisor-based isolation with runtime-defined environments and GPU access | Modal | | Persistent Linux environments with automatic idle behaviour and checkpointing | Fly.io Sprites | | Firecracker microVM execution within the Vercel ecosystem | Vercel Sandbox | | VM-isolated containers integrated with Cloudflare Workers | Cloudflare Sandbox | | MicroVM sandboxes with snapshot and restore for AI agents and code playgrounds | CodeSandbox | ### How do sandbox runners compare on pricing? Pricing checked in September 2026. Hourly equivalents are rounded where needed; Vercel rates shown are for its default region. Billing models differ across platforms (some bill based on active CPU usage only, others bill for the entire duration the sandbox is running). Verify current rates on each platform's pricing page before making cost decisions. | Platform | CPU | Memory | Storage | GPU | Billing model | | --- | --- | --- | --- | --- | --- | | **Northflank** | $0.01667/vCPU-hr | $0.00833/GB-hr | $0.15/GB-month | L4: $0.80/hr, A100 40GB: $1.42/hr, A100 80GB: $1.76/hr, H100: $2.74/hr | Per second | | **Fly.io Sprites** | $0.07/CPU-hr | $0.04375/GB-hr | $0.000683/GB-hr hot; $0.000027/GB-hr cold | Do not provide GPU compute | Actual usage, metered hourly; idle compute is free, retained storage is billed | | **Cloudflare Sandbox** | $0.072/vCPU-hr | $0.009/GiB-hr | $0.000252/GB-hr | Do not provide GPU compute | Active CPU; memory and disk provisioned. Requires $5/month Workers Paid plan; Workers and Durable Objects usage also billed | | **CodeSandbox** | Pico VM: $0.075/hour (1 core) | 2 GB included in starting VM tier | 20 GB per VM on standard plans | Do not provide GPU compute | VM credits; prices before subscription savings | | **E2B** | $0.0504/vCPU-hr | $0.0162/GiB-hr | 10–20GB included free | Do not provide GPU compute | Per second | | **Modal Sandboxes** | $0.1419/physical core-hr (2 vCPU) | $0.0240/GiB-hr | — | L4: $0.80/hr, A100 40GB: $2.10/hr, A100 80GB: $2.50/hr, H100: $3.95/hr, H200: $4.54/hr | Per second | | **Vercel Sandbox** | $0.128/vCPU-hr | $0.0212/GB-hr | $0.08/GB-month (snapshots) | Do not provide GPU compute | Active CPU; provisioned memory and other usage metered separately | Billing units differ: CodeSandbox includes CPU and RAM in its VM price, while Modal charges per physical core (two vCPUs). **Fly.io Sprites pricing update:** From October 1, 2026, CPU costs $0.03825/CPU-hour and memory costs $0.021875/GB-hour. Storage rates remain unchanged. ### Bring your own cloud (BYOC) support across sandbox runners The table below shows how each platform handles bring your own cloud (BYOC) deployment, which clouds are supported, and whether it requires a sales process. | Platform | Bring your own cloud (BYOC) available | Clouds supported | Access model | Pricing model | | --- | --- | --- | --- | --- | | **Northflank** | Yes, fully self-serve | AWS, GCP, Azure, and supported Kubernetes infrastructure, including on-premises and bare-metal | Self-serve, enterprise contracts available for larger commits (with bulk discounts) | Cloud infrastructure costs plus Northflank management charges | | **E2B** | Yes, limited and not self-serve | AWS, GCP, and Azure | Not publicly disclosed, need to contact sales | Custom Enterprise pricing plus cloud infrastructure costs | | **Modal** | No | Managed only | — | — | | **Fly.io Sprites** | No | Managed only | — | — | | **Vercel Sandbox** | No | Managed only, multiple regions | — | — | | **Cloudflare Sandbox** | No | Managed only | — | — | | **CodeSandbox** | No | Managed only | — | — | ## FAQ: Common questions about sandbox runners The questions below cover what engineering teams most commonly ask when evaluating sandbox runners. ### What is the difference between a sandbox runner and a development environment? A sandbox runner is designed to execute arbitrary or untrusted code safely, typically for AI agents, user-submitted scripts, or code interpretation. A development environment is designed for developers to write, run, and iterate on code they own. Some platforms serve both purposes, but the security requirements and isolation models differ significantly between the two use cases. ### Which sandbox runners support self-serve bring your own cloud (BYOC)? Northflank offers self-serve bring your own cloud (BYOC) on supported cloud and Kubernetes infrastructure. It acts as the control plane to run coding agents and their sandboxes in your virtual private cloud (VPC). E2B bring your own cloud (BYOC) is available on Enterprise for AWS, GCP, and Azure and requires contacting their team. Modal, Vercel Sandbox, Cloudflare Sandbox, and Fly.io Sprites run on the vendor's infrastructure only. ### Which sandbox runners support persistent environments? Northflank supports both ephemeral and persistent environments with no forced time limits. Fly.io Sprites maintain a persistent filesystem across sessions with automatic idle behaviour. E2B supports persistent state via pause and resume, with session limits that depend on the plan. CodeSandbox supports persistence through snapshots and hibernation. Modal supports snapshot-based state preservation. Cloudflare Sandbox local state resets when its container stops; mounted object storage or backups can preserve files. Vercel Sandbox sessions run up to 24 hours on Pro and Enterprise with snapshotting available. ### Which sandbox runners support GPU workloads? Northflank supports sandboxed GPU workloads with NVIDIA H100, A100, L4, and other GPU options. Modal also provides GPU access configurable per sandbox. ## Related articles on sandbox runners The articles below go deeper on isolation technologies, deployment models, and sandbox infrastructure covered in this guide. - [What is an AI sandbox?](https://northflank.com/blog/what-is-an-ai-sandbox): A detailed explainer on AI sandbox infrastructure, isolation models, and use cases. - [Top AI sandbox platforms for code execution](https://northflank.com/blog/top-ai-sandbox-platforms-for-code-execution): A full ranked comparison of AI sandbox platforms with pricing, isolation, and session lifecycle breakdowns. - [Kata Containers vs Firecracker vs gVisor](https://northflank.com/blog/kata-containers-vs-firecracker-vs-gvisor): A technical comparison of the isolation technologies used across the sandbox runners in this guide. - [Top bring your own cloud (BYOC) AI sandboxes](https://northflank.com/blog/top-byoc-ai-sandboxes): A comparison of sandbox providers that support deployment inside your own cloud infrastructure. - [Self-hosted AI sandboxes](https://northflank.com/blog/self-hosted-ai-sandboxes): Covers the three deployment models for running sandbox infrastructure in your own infrastructure. - [Ephemeral sandbox environments](https://northflank.com/blog/ephemeral-sandbox-environments): Explains the tradeoffs between ephemeral and persistent sandbox models and when each fits the workload.

How to create secure preview environments with isolated sandboxes

2026-09-18T15:02:00.000Z

A pull request can change the application, its dependencies, and the scripts that run during a build. If its preview inherits production credentials or unrestricted access to internal services, code awaiting review already has more authority than it needs. Creating secure preview environments with isolated sandboxes means controlling both where that code executes and what it can reach. This guide covers the runtime boundary, configuration, data, networking, reviewer access, and checks needed to keep each preview contained throughout its lifecycle. ## TL;DR: How to create secure preview environments Create secure preview environments by combining sandboxed execution with scoped credentials, isolated test state, explicit network permissions, and automated teardown. - Contain both the build and the running application; dependency installation also executes code. - Keep preview administration outside the authority of the branch being tested. - Give each preview its own writable state and narrowly scoped non-production credentials. - Authenticate reviewer access and allow only the network destinations the preview needs. - Test forbidden actions as well as application functionality, then confirm that cleanup removes access and resources. If your teams need full application previews alongside isolated execution, Northflank provides [Preview Blueprints](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) and [sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank). Northflank is an AI-agent sandbox and workload platform for running untrusted code in isolated environments on [Northflank Cloud](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-on-northflank) or in [your own cloud account and VPC](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-in-your-cloud). [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss preview architecture, sandbox isolation, or cloud requirements. ## What does an isolated sandbox protect in a preview environment? An isolated sandbox limits how application code interacts with the host and neighbouring workloads. The preview environment is the application instance reviewers use; its services can run inside sandboxed execution environments. A separate branch or preview URL identifies the change under review, but it does not determine how the application is isolated from the infrastructure running it. The execution environment needs its own protections against code accessing the host or interfering with other workloads. For previews that run unreviewed code, choose a sandbox that provides that separation. A microVM gives the workload a lightweight virtual machine with its own operating-system kernel. Your team still needs to decide which services, data, and credentials the application can access. The sandbox does not decide whether a database password should permit production writes. If the application receives a valid credential and can reach its target, sandboxing does not make that access safe. Design runtime isolation, permissions, and network access together. ## How do you create secure preview environments with isolated sandboxes? Start with a trusted environment definition, then provision the application with only the resources and permissions needed to review its change. Let’s use a checkout pull request as an example. Its preview needs a frontend, API, worker, database, queue, and payment test endpoint. The steps below show how to create that environment securely. ### 1. Separate untrusted code from preview administration Keep the credentials that create environments outside the code being previewed. Use a trusted workflow to select the repository and candidate commit, apply policy, and request the preview. Run branch-controlled build commands in a restricted environment. Give that build only the package or repository access it needs, and keep deployment-administration credentials out of its environment. For external contributions, require review before granting access beyond the restricted baseline. Tie that decision to the commit being executed so a later push cannot inherit approval for different code. Check the build stage as carefully as the deployed application. A dependency installation or test script can use credentials available to that process. A preview should not gain permission to change shared infrastructure simply because its build needs to download a private package. ### 2. Run preview workloads in isolated sandboxes Choose an execution environment that contains the preview's code and keeps infrastructure administration outside its reach. The checkout API needs to process test orders. It does not need access to the underlying server, another team's files, or the controls used to create and delete environments. Keep those permissions outside the preview, including when developers change its startup commands or dependencies. If your team needs managed execution for unreviewed code, Northflank provides [sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank). On its managed cloud, [sandbox workloads run with microVM isolation](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-on-northflank), giving each workload a separate execution boundary. Test the application and its dependencies in that environment before making it your standard preview configuration. Confirm that builds, background jobs, and file operations work with the permissions you intend to allow. ### 3. Create the application and its test state together Provision writable dependencies within the preview's access boundary. For the checkout example, create a fresh database with synthetic orders and customers. Give the worker a dedicated queue or a broker identity restricted to that preview's destinations. A queue prefix helps organise resources, but permissions must prevent a worker from consuming another preview's messages. Send payments, emails, and webhooks to test systems. Generate callback addresses from the preview's identity so a test transaction returns to the correct application. If your team needs repeatable provisioning, Northflank provides [Preview Blueprints](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) to assemble services, database addons, and seed jobs. This lets the preview's application and test data follow one creation sequence. The guide to [database strategies for preview environments](https://northflank.com/blog/which-database-strategy-should-you-use-for-preview-environments) covers the trade-offs between fresh data and copies of existing state. ### 4. Give each preview its own credentials Issue credentials for the preview's dependencies and limit what those credentials permit. Separate build access, application access, migration access, and environment administration. A migration job may need schema-changing permissions that the running API does not. Keep production credentials out of all four paths. If several components need configuration, Northflank provides [secret groups](https://northflank.com/docs/v1/application/secure/manage-secret-groups) with build-time and runtime scopes and recipient restrictions. Configure those restrictions deliberately: an unrestricted group is inherited by applicable services and jobs across its project. Check which workloads receive each group without printing secret values. Then test the credential's underlying permissions. Restricting secret distribution does not reduce the authority of a broadly privileged database user. ### 5. Restrict incoming and outgoing traffic Allow the preview's required connections and deny unrelated destinations. For checkout, permit the frontend to call its API and allow the API and worker to reach their database, queue, and payment test endpoint. Keep production networks, other previews, and management endpoints outside that allowed set. Include DNS and required infrastructure traffic when defining the rules. Begin with the connections the application needs, then check that everything outside that list is blocked. A private database address controls how the database is reached; it does not, by itself, stop the application from sending data elsewhere. Test outgoing connections as well as access to the preview. If you need private service communication, Northflank provides [internal networking](https://northflank.com/docs/v1/application/network/networking-on-northflank). Internal endpoints are accessible within the same project by default. When several previews share a project, enforce the additional separation between them instead of treating private endpoints as proof of per-preview isolation. ### 6. Protect the URL reviewers use Place reviewer authentication outside the application code being tested. A branch can change its own login checks. Use a separately managed access policy for private previews, and grant reviewers access without giving them deployment-administration permissions. If your preview needs protected HTTP entrypoints, Northflank supports [path-based security policies](https://northflank.com/docs/v1/application/network/create-path-based-security-policies) with Basic Authentication, HTTP-header checks, and IP rules. You can also require SSO when your team belongs to an organisation with SSO and directory sync configured. Check generated URLs, custom domains, API paths, and alternate ports. Private traffic bypasses these policies by default, although you can require internal traffic to pass through SSO. Keep network restrictions in place alongside reviewer authentication. Scope test login sessions and callback registrations to the intended preview. A working login is insufficient if it redirects the reviewer to shared staging or another pull request. ### 7. Set limits and teardown before enabling automation Give every preview an owner, resource budget, and expiry before accepting automatic triggers. Bound CPU, memory, storage, build duration, and concurrent environments. Size the full checkout stack, including its database and worker, rather than budgeting only for the frontend. Keep a maximum lifetime even when a pull request remains open. If your team needs lifecycle automation, Northflank supports [preview expiry and Git-triggered deletion](https://northflank.com/docs/v1/application/release/manage-preview-blueprints). Expiry uses a configured lifetime, with an option to reset the timer when the preview runs again. Include external resources in the deletion plan. Northflank supports [teardown specifications](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) for cleanup beyond normal preview deletion. Test partial creation failures too: a failed deployment may still leave a database, test account, or callback registration behind. ## How do you test whether a preview is actually isolated? Test that required actions succeed and forbidden actions fail from the running preview. Create two previews with synthetic data. Use one as the candidate and the other as a control. Keep tests within infrastructure you own or are authorised to assess; use a representative protected test endpoint instead of attempting writes against production. | Check | Expected result | | --- | --- | | Complete a checkout in preview A | Its API, worker, and test database process the same transaction | | Connect from A to preview B's private API | Connection is blocked where cross-preview access is forbidden | | Use A's database identity against B's data | Access is denied; B's synthetic marker records remain unchanged | | Publish or consume outside A's permitted queues | Broker permissions reject the operation | | Contact an unapproved external test destination | Egress is denied while approved dependencies remain reachable | | Attempt to access infrastructure administration from the preview | The application cannot obtain administrative credentials or manage the hosting environment | | Open each reviewer endpoint without authentication | Access is denied or authentication is required | | Close or expire A | Preview resources are deleted, external credentials are revoked, and external cleanup completes | Run these checks against the environment your reviewers will use. Confirm the permissions from inside the application, because a settings page alone cannot show whether every access restriction works as intended. Record the commit, image digest, policy version, resource inventory, and test outcomes. Keep secrets out of retained logs. If a check fails, the [preview troubleshooting guide](https://northflank.com/blog/preview-environment-troubleshooting) helps trace the application and infrastructure path. Maintain an independent way to stop workloads, revoke credentials, and disable routes. Pausing future triggers alone is insufficient containment for an already running preview. ## How does Northflank support secure preview environments? [Northflank](https://northflank.com/product/preview-environments) brings application previews, sandboxed execution, private networking, secrets, and cleanup into one platform. If your enterprise needs that combination on managed infrastructure or in your own cloud account, we recommend Northflank as the default choice for this workflow. Start with a project on [Northflank Cloud](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-on-northflank), where sandbox workloads use microVM isolation by default. A Preview Blueprint creates and manages the preview's application resources; the project's execution infrastructure provides their runtime isolation. To run workloads in your own cloud account, use [BYOC](https://northflank.com/docs/v1/application/bring-your-own-cloud/use-other-cloud-providers-with-northflank). You own the account, and Northflank provisions and manages Kubernetes there. With BYOC, configure [sandbox-enabled node pools](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-in-your-cloud) and workload placement. Runtime availability depends on the provider and region, so confirm the selected infrastructure supports the isolation you require. In the project, open **Environments**, [create a Preview Blueprint](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints), and connect its pull-request trigger. Add the application resources and configure the controls above. Keep the blueprint's administrative settings under trusted ownership. Test a selected commit manually before enabling the wider workflow. If your previews need to run in your own cloud account, use BYOC and configure build, log, and backup storage to match your [data requirements](https://northflank.com/security). Your team controls who can access each preview, which test data it uses, and the checks it must pass. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss standardising secure previews across your teams. ## Frequently asked questions about secure preview environments ### Is an ephemeral preview automatically secure? No. A short lifetime reduces how long resources remain active, but the preview can still misuse its permissions while running. Apply isolation and access controls before execution begins. ### Can previews share a database server? Yes, when separate databases or schemas have appropriately restricted identities and the shared server's resource and failure risks are acceptable. Use separate instances when testing requires a stronger boundary. Different database names with one unrestricted credential are insufficient. ### Does AI-generated code need a different preview process? Apply the same trust-based controls to human-written and AI-generated changes. Review the actual code, dependencies, and requested access. Keep the coding workspace separate from application review and production release; the guide to [deploying coding agents at scale](https://northflank.com/blog/deploy-coding-agents-at-scale) explains that broader workflow. ## Related articles about preview environments and sandboxed development Continue with these guides to architecture, automation, and troubleshooting. - [Preview environments for microservices: Architecture and common pitfalls](https://northflank.com/blog/preview-environments-microservices) - [Preview environment troubleshooting: Common failures and how to fix them](https://northflank.com/blog/preview-environment-troubleshooting) - [Which database strategy should you use for preview environments?](https://northflank.com/blog/which-database-strategy-should-you-use-for-preview-environments) - [How to auto-create preview environments on every PR](https://northflank.com/blog/how-to-auto-create-preview-environments-on-every-pr) - [How to deploy coding agents at scale](https://northflank.com/blog/deploy-coding-agents-at-scale)

Coding-agent orchestration: How to manage agents across enterprise teams

2026-09-18T15:00:00.000Z

Coding agents working across several engineering teams can produce overlapping changes, consume shared test capacity, and leave work waiting for an owner. Your teams need a consistent way to assign tasks, control access, coordinate dependencies, and review the results. Coding-agent orchestration connects task assignment, execution, and review. This guide explains how to organize that workflow across teams, with clear ownership, controlled workspaces, and a defined path to accepted changes. ## TL;DR: How to manage coding agents across enterprise teams Manage coding agents through clearly owned tasks, controlled workspaces, explicit dependencies, and a shared process for reviewing and accepting changes. - Give every task an owner, repository revision, expected result, and acceptance checks. - Run independent tasks concurrently and sequence work that depends on shared interfaces or artifacts. - Keep workspaces, credentials, and retained context within the appropriate team and task boundaries. - Validate the integrated change and keep merge and release authority explicit. - Match concurrency to model, compute, CI, and review capacity, with limits on retries and unfinished work. If your teams need a shared way to run coding agents such as Claude Code and Codex, [Northflank Cloud Harnesses](https://northflank.com/docs/v1/application/cloud-harness/quickstart) provide configurable cloud coding environments with repository integration and dashboard or SSH access, on managed infrastructure or in your own cloud. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your team's requirements. ## What is coding-agent orchestration? Coding-agent orchestration coordinates task assignment, agent execution, dependencies, permissions, and results across a software-delivery workflow. The coding agent inspects code, makes changes, and uses tools. Its execution environment provides the filesystem, processes, and dependencies needed to do that work. A coordinator tracks assignments and progress, while repository and release systems determine which changes can merge and deploy. Your organization can coordinate many single-agent tasks without requiring agents to delegate to one another. ## Who should own coding agents across engineering teams? Platform teams should own shared execution services, while engineering teams retain ownership of their repositories, task requirements, and accepted changes. Assign responsibility for execution, access, and delivery before introducing agents across teams. In smaller organizations, one team may hold several responsibilities. | Owner | Responsibility | Decision retained | | --- | --- | --- | | Platform engineering | Runtime configuration, execution capacity, workspace lifecycle, telemetry | Approved execution environments and resource limits | | Product or service team | Task scope, repository context, acceptance criteria | Whether the change solves the intended problem | | Security and identity owners | Access boundaries, sensitive data, exceptions | Permission expansion and containment policy | | Repository and release owners | Integration checks, review, rollout | Merge and production release | Assign an escalation owner before starting work. If an agent needs access to another team's service, the task should move to an explicit blocked state with someone responsible for resolving it. ## How should you coordinate coding-agent tasks across teams? Make task scope, dependencies, handoffs, and acceptance conditions explicit before choosing how many agents to run. Start with these four practices. ### 1. Define bounded tasks and consistent agent configurations Each task needs an owner, repository revision, expected output, and checks that establish completion. “Update the internal client library to the agreed version and pass the compatibility tests” gives an agent a more useful boundary than “modernize this service.” Record the starting commit, allowed repositories, relevant data, reviewer, and limits on duration and resource use. Version the agent configuration, tools, instructions, and runtime image so your team can investigate why two runs behaved differently. A repository instruction should not grant access that the task was never authorized to use. Keep trusted acceptance criteria outside the agent's control. Changes to tests may be legitimate, but reviewers should be able to see when the agent changed the checks used to judge its own work. ### 2. Choose sequential, parallel, or delegated execution Choose the execution pattern according to dependencies and how independently each result can be evaluated. Sequential execution suits work where one result establishes the next task's input, such as agreeing a schema before updating its consumers. Parallel execution suits independent changes with separate validation, such as updating unrelated repositories to an already approved dependency version. Delegated execution lets a coordinating agent assign bounded subtasks to workers and assemble their results. Give each child task its own scope and completion condition, while keeping its resource use within the parent budget. Start with the simplest pattern that fits the task. Splitting a tightly coupled change can create more integration work than it saves. ### 3. Pass explicit artifacts between dependent tasks A handoff should identify the code revision, test outcome, unresolved questions, and receiving owner. For example, a consumer team needs the exact library version and interface change its agent should use. A message saying “the library is ready” leaves too much room for a worker to choose a different revision or assume missing behavior. Pass a commit, patch, or artifact reference with its test results and review status. Share only the context the receiving task is allowed to access. Credentials and unrelated team data should stay outside the handoff. Treat another agent's output as an input to validate; tool permissions must remain enforced by the systems receiving the action. ### 4. Preserve task state and recover uncertain runs Store task ownership and progress outside the execution workspace so a restarted worker can check what already happened. Use a stable task identifier and a separate identifier for each attempt. Record whether work is queued, running, blocked, awaiting review, accepted, or stopped. Automated workers can use a lease, a temporary claim they renew while working, to establish current ownership. A timed-out request may already have created a branch, pull request, or environment. Check for that result before repeating the operation. Bound retries and route persistent failures to the owner. Cancellation should reach child tasks and external operations as well as the main agent. Record whether each worker and external operation has actually stopped. ## What do coding agents need from a shared execution environment? Coding agents need consistent runtimes, suitable resources, scoped access, and a clear policy for collaboration and retained state. Give independent tasks separate working copies and execution boundaries appropriate to the code they run. [Git worktrees](https://git-scm.com/docs/git-worktree) let a repository have multiple working trees, but some repository state remains shared. They organize concurrent editing; process, filesystem, and network isolation require separate controls. Prepare the languages, tools, and dependencies needed for the repository. Scope credentials to the required services and restrict network access deliberately. Keep fleet administration and production-release credentials outside the coding workspace. The guide to [AI-agent code-execution infrastructure](https://northflank.com/blog/ai-agent-code-execution-infrastructure) explains these boundaries in more detail. When engineers need to inspect work together, Northflank provides [Cloud Harnesses with shared team access](https://northflank.com/docs/v1/application/cloud-harness/quickstart). Teammates can collaborate in the same cloud coding environment through the dashboard or connect from their terminals using SSH. Establish who is editing or running commands during that shared session. Retained workspaces need an owner and an expiry policy. Preserve selected files for longer tasks and handoffs, then remove stale credentials, caches, and data according to their sensitivity. ## How do you prevent conflicting changes and review agent output? Coordinate overlapping work before execution and validate the exact candidate after integration. Assign an owner to shared libraries, interfaces, and schema changes. Separate branches make changes easier to review, but two agents editing different files can still introduce incompatible assumptions. Sequence dependent work and flag overlapping tasks before they become competing pull requests. Run trusted checks against the candidate that will actually merge. Revalidate when integration changes it, and inspect modifications to tests or release configuration. Tie test results and approvals to the candidate revision so an earlier result cannot silently stand in for a later change. If reviewers need to inspect the running application, Northflank provides [preview blueprints](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) for creating application environments from repository changes. Its [Workflows](https://northflank.com/docs/v1/application/release/configure-workflows) connect builds, jobs, deployments, and configured approval steps. ## What does a cross-team coding-agent workflow look like? Update the shared library first, then assign each team the changes needed in its own service. Consider an internal API client used by a billing service and an account-management service. For example, organize the work as follows: 1. **Agree the change.** The library owner defines the intended interface and compatibility requirements. Each consumer team identifies its reviewer. 2. **Prepare the library.** An agent produces a candidate revision and test results in its assigned workspace. The owner reviews the interface before downstream work starts. 3. **Update consumers.** Each service team assigns its agent the same approved library revision, with a separate branch and service-specific tests. 4. **Validate integration.** Teams test the combined behavior. A failing billing check blocks that dependent rollout and returns evidence to the responsible owner. 5. **Release and close.** Repository owners accept their changes, releases follow a compatible order, and workspace owners preserve required output before cleanup. Each team owns its service changes and knows which library revision it must use. ## How should you control cost, failures, and review capacity? Limit concurrent work against your actual delivery capacity and measure the cost and quality of accepted changes. Set team budgets and per-task limits covering model calls, compute, duration, and retries. Include delegated work in those limits. Allocate capacity so a large batch from one team cannot consume every worker or test slot. Watch review queues alongside execution queues. When agents produce changes faster than engineers can evaluate them, reduce new assignments or narrow their scope. Track time to acceptance, review effort, rework, and defects by task type. Include failed attempts when calculating cost per accepted change. Pause or remove inactive workspaces according to retention needs, and confirm cleanup rather than treating a deletion request as completion. Operators should be able to terminate execution, revoke access, quarantine retained state, and prevent further assignments independently of the agent. Connect task identifiers to revisions, approvals, execution resources, and outcomes. Capture prompts and outputs only where policy permits. An [AI-agent code execution audit trail](https://northflank.com/blog/ai-agent-code-execution-audit-trail) should help operators reconstruct what happened without collecting unnecessary sensitive content. Before expanding autonomy, test malicious repository instructions, permission-escalation attempts, poisoned handoffs, and approval bypass alongside normal engineering tasks. Exercise cancellation and recovery as part of that evaluation. ## How can Northflank Cloud Harnesses support coding-agent orchestration? [Northflank Cloud Harnesses](https://northflank.com/docs/v1/application/cloud-harness/quickstart) give your teams managed cloud coding environments for agents such as Claude Code, Codex, OpenCode, Cursor, and Pi, with an option to bring your own agent. Your platform team can prepare suitable runtime images and resource configurations while engineers connect their agents and repositories. Task assignment, dependency handling, and acceptance remain with your agent tools and engineering workflow. [Cloud Harness configuration and lifecycle controls](https://northflank.com/docs/v1/application/cloud-harness/configure-and-manage-cloud-harnesses) cover resources, workspace storage, environment variables, networking, and CPU and memory monitoring. Pausing scales the Cloud Harness to zero, stopping running terminal sessions and processes while preserving workspace files. After resuming, engineers may need to restart the commands or processes required for their session. Export required work before deleting a Cloud Harness and its associated workspace. Run on managed infrastructure or in your own cloud account. With [bring your own cloud](https://northflank.com/product/bring-your-own-cloud) (BYOC), Northflank provisions and manages Kubernetes in your account. If your enterprise needs shared coding workspaces on managed infrastructure or in your own cloud, Northflank Cloud Harnesses let your teams run coding agents and collaborate in the same environment. Start with a [Pay As You Go account](https://northflank.com/pricing), authenticate your coding agent, connect a repository, and configure a workspace for your first task. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss coding-agent workspaces, team access, and deployment in your own cloud. ## Frequently asked questions about coding-agent orchestration ### Do you need multiple coding agents for every task? No. Use multiple agents when independent subtasks and clear handoffs justify the coordination effort. A tightly coupled change may be easier to complete and evaluate with one agent. ### Can coding agents work in the same repository? Yes. Define task boundaries, use separate working copies where appropriate, and control integration. Separate branches still need checks for incompatible changes to shared behavior. ### Can an agent review another agent's code? An agent can contribute review evidence, such as identifying missing tests or suspicious changes. Keep trusted acceptance checks and authorized merge and release decisions in place. Require human approval according to the change's impact and delegated authority. ### Should coding-agent workspaces be persistent? It depends on the task. Retained files help with longer work and handoffs. Independent tasks benefit from clean environments. Define access, retention, and deletion for persistent state separately from the running compute. ## Related articles about coding-agent orchestration For more detail on deployment, execution controls, and audit trails, read these guides. - [How to deploy coding agents at scale](https://northflank.com/blog/deploy-coding-agents-at-scale) - [How to run AI coding agents in a secure sandbox](https://northflank.com/blog/how-to-run-ai-coding-agents-in-a-secure-sandbox) - [What infrastructure do AI agents need to run code safely?](https://northflank.com/blog/ai-agent-code-execution-infrastructure) - [What should an audit trail for AI-agent code execution contain?](https://northflank.com/blog/ai-agent-code-execution-audit-trail)

Northflank vs Fly.io Sprites: which platform fits your requirements?

2026-09-18T15:00:00.000Z

## TL;DR: Northflank vs Fly Sprites - **Fly Sprites fit teams that want persistent Linux environments for AI agents**, with Firecracker isolation, durable filesystems, automatic sleep and wake, and checkpoints. - **Northflank fits startups, enterprises, platform and AI teams that need production-grade isolated execution and the infrastructure around it**, with microVM-backed Sandboxes, GPUs, services, workers, jobs, managed databases, persistent volumes, Preview Blueprints, Harnesses, and workflows. - **The key differences are persistence, GPU support, and infrastructure ownership:** Sprites are persistent by default and run on Fly.io infrastructure, while Northflank Sandboxes are ephemeral by default with optional persistent volumes, support GPU-backed execution, and can run on Northflank Cloud, BYOC, or eligible BYOK infrastructure. > [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss AI infrastructure, security, compliance, or customer-cloud deployment. > Northflank and Fly Sprites both provide isolated environments for running AI agents and untrusted code, but they take different approaches. Fly Sprites package Firecracker microVMs as persistent Linux environments with state that survives between sessions, while Northflank provides production-grade ****microVM-backed Sandboxes alongside the broader application stack, including APIs, workers, jobs, managed databases, GPU workloads, preview environments, and BYOC into your own cloud. The key difference is scope. Sprites are built around persistent agent environments, while Northflank combines isolated execution with the infrastructure needed to build and run production applications around it. This comparison covers lifecycle, isolation, persistence, networking, GPU support, developer experience, security, pricing, and when each platform fits. ## Northflank vs Fly Sprites: comparison table Product and plan details are current as of September 2026. | Requirement | Northflank | Fly Sprites | | --- | --- | --- | | **Best for** | AI, platform, and engineering teams that need production-grade isolated execution alongside applications, GPUs, databases, and production infrastructure | Developers building persistent Linux environments for AI agents and arbitrary code | | **Product scope** | Sandboxes plus services, workers, jobs, databases, queues, volumes, GPUs, workflows, and previews | Persistent Linux environments focused on agent and code execution | | **Isolation** | MicroVM-backed isolation with Kata Containers and Cloud Hypervisor, with Firecracker and gVisor available where appropriate | Firecracker microVM with its own kernel and isolated resources | | **Persistence** | Ephemeral root filesystem by default, with persistent volumes for state that must survive restarts and scale-to-zero | Persistent ext4 filesystem that survives pauses and wakes automatically | | **Lifecycle** | Sub-second startup, scale to zero, restart, resume, or destroy; no fixed sandbox session duration | Active, warm, and cold states with automatic pause and wake | | **Resources** | Configurable CPU and memory, custom resource plans, plus GPU resources | 8 vCPUs per Sprite, 100 GB storage, with memory managed by the platform | | **GPU** | GPU-backed Sandboxes, services, and jobs on supported managed cloud and BYOC infrastructure | No GPU | | **Storage** | Ephemeral root filesystem with optional persistent volumes | Persistent filesystem with durable storage and checkpoints | | **Networking** | Public and private ports, private networking, network policies, static egress, and BYOC VPC routing | Sprite URLs, private networking, and configurable egress policies | | **Credential brokering** | Secret groups for securely injecting credentials into workloads | Connectors broker credentials to external services without exposing the underlying token to the Sprite | | **Agent support** | Sandboxes, Cloud Harnesses, Agent Skills, and GPU workloads | MCP, Connectors, and agent integrations | | **Supporting stack** | APIs, services, workers, jobs, managed databases, queues, storage, GPUs, and previews in one platform | Sprite compute and agent tooling; surrounding application infrastructure is separate | | **Preview environments** | Full-stack Preview Blueprints with applications, databases, jobs, volumes, networking, and URLs | No equivalent native full-stack preview orchestration | | **Infrastructure** | Northflank Cloud, BYOC, and BYOK | Fly.io managed infrastructure | | **Enterprise controls** | Granular RBAC, SAML/OIDC SSO, directory sync, audit logs, scoped API access, and customer-controlled infrastructure | Organisation-level access controls, API tokens, Connectors, and network policies | | **Pricing** | Per-second resource pricing with no PAYG seat fees; BYOC platform fees plus cloud infrastructure costs | CPU, memory, and storage usage billed based on active usage | ## How do Northflank and Fly Sprites compare on sandbox lifecycle and persistence? ### Fly Sprites Fly Sprites are persistent by default. Their filesystem survives pauses, so installed packages, repositories, databases, and other files remain available when the Sprite wakes. Sprites automatically move between active, warm, and cold states, with warm wakes preserving process state and cold wakes starting processes again. ### Northflank Northflank Sandboxes use an ephemeral root filesystem by default. Teams can attach [persistent volumes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) when repositories, datasets, models, or agent state need to survive restarts and scale-to-zero. Scaling a Sandbox to zero stops compute billing while keeping its volume and configuration intact. The result is a different persistence model. Sprites make persistence automatic, while Northflank lets teams choose what should persist and what should remain ephemeral. That is useful when the same sandbox infrastructure needs to support both short-lived code execution and longer-running workloads. ## How do Northflank and Fly Sprites compare on templates, startup, and scaling? ### Fly Sprites Fly Sprites can boot in under one second from a cold state, while warm wakes can return in 100–500 ms with process state preserved. Checkpoints capture the filesystem state using copy-on-write, allowing developers to create reusable states without interrupting the running Sprite. Sprites currently use a fixed 8 vCPU configuration, while memory is managed automatically by the platform. Sprites do not currently autoscale, so scaling out means provisioning additional Sprites rather than resizing an existing one. Automatic pause and wake handles idle workloads, while the Tasks API can keep a Sprite active while work is running. ### Northflank Northflank Sandboxes boot in under one second and support configurable CPU and memory resources. [Templates](https://northflank.com/docs/v1/application/infrastructure-as-code/create-a-template) let teams define and reproduce platform resources and workflows rather than relying on VM snapshots, and Northflank has demonstrated 100,000+ concurrent Sandboxes in its [2026 Scale Invitational benchmark by ComputeSDK](https://platform.computesdk.com/scale-invitational/northflank). Northflank Sandboxes support configurable CPU and memory resources and scale-to-zero. At the broader platform level, Northflank also supports horizontal autoscaling based on CPU, memory, requests per second, and custom Prometheus metrics. ## How do Northflank and Fly Sprites compare on storage, networking, and GPU support? ### Fly Sprites Each Sprite includes up to 100 GB of persistent storage, with data continuously synced to durable storage. Sprites also provide a unique HTTPS URL and configurable network policies for controlling outbound access. Fly's Connectors broker credentials for services such as GitHub, Anthropic, OpenAI, and S3-compatible storage, so Sprites can use external APIs without directly holding the underlying credentials. ### Northflank Northflank Sandboxes use an ephemeral root filesystem with optional [persistent volumes](https://northflank.com/docs/v1/application/databases-and-persistence/add-a-volume). Networking includes public and private ports, private service discovery, [multi-project networking](https://northflank.com/docs/v1/application/network/enable-multi-project-networking), [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies), static egress, and BYOC VPC routing. [Secret groups](https://northflank.com/docs/v1/application/secure/manage-secret-groups) provide encrypted credential injection for services and Sandboxes. Northflank also supports [GPU-backed Sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank), model-serving services, and jobs on supported GPU infrastructure. This means teams can combine isolated execution with GPU inference and other accelerator workloads without moving that compute to a separate platform. ## How do Northflank and Fly Sprites compare on developer experience? ### Fly Sprites Fly Sprites centers the experience on the `sprite` CLI and API. Developers can create Sprites, run commands, open interactive sessions, manage services, and create checkpoints from the CLI, while Sprites provide common development runtimes and AI tools out of the box. Sprites also provide agent-focused integrations through MCP, SDKs, and Connectors, making it straightforward to give coding agents an isolated environment with access to external services. ### Northflank Northflank provides Git-to-deploy, Dockerfiles, Buildpacks, external images, [Workflows](https://northflank.com/docs/v1/application/release/configure-workflows), [Templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code), [GitOps](https://northflank.com/docs/v1/application/infrastructure-as-code/gitops-on-northflank), API, CLI, and SDKs. For AI development, [Northflank Skills](https://github.com/northflank/skills) let agents such as Claude Code, Codex, Cursor, and OpenCode deploy and manage infrastructure, while [Harnesses](https://northflank.com/docs/v1/application/ai-agents/harnesses/quickstart) provide dedicated cloud environments for AI coding agents with their own resources and networking. ## How do Northflank and Fly Sprites compare on previews and production infrastructure? ### Fly Sprites Sprites are primarily focused on isolated execution environments. They provide persistent compute, services, URLs, and agent tooling, but the broader production architecture around an application, such as APIs, databases, and other services, needs to be built separately on the Fly platform or elsewhere. ### Northflank Northflank [Preview Blueprints](https://northflank.com/docs/v1/application/release/manage-preview-blueprints) create complete preview environments with services, databases, jobs, volumes, networking, and configuration. The same platform provides managed databases, GPUs, queues, persistent infrastructure, and the deployment workflows needed to move that architecture into production. Northflank also supports Northflank Cloud, BYOC, and BYOK, so teams can run the sandbox and its supporting application infrastructure on Northflank's managed cloud, in their own cloud account, or on eligible existing Kubernetes infrastructure. ## How do Northflank and Fly Sprites compare on security, isolation, and observability? ### Fly Sprites Each Sprite runs in its own Firecracker microVM with its own kernel, filesystem, and network namespace. Sprites also provide outbound network policies and Connectors that broker credentials for external services without exposing the underlying provider token to the Sprite. Sprites currently do not provide a fine-grained RBAC model for controlling access to individual Sprite resources. Authentication uses Fly.io accounts and scoped API tokens, while agent access can be restricted through Connector policies. ### Northflank Northflank Sandboxes use microVM-backed isolation with a separate kernel, while the platform adds [granular RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), SAML/OIDC SSO, directory sync, scoped API access, and [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs). Northflank Enterprise also supports forward-deployed and air-gapped environments for stricter infrastructure requirements. Northflank also provides logs, metrics, health checks, alerts, and [log sinks](https://northflank.com/docs/v1/application/observe/configure-log-sinks) across sandboxes and the rest of the application stack. This gives platform teams security and observability controls at both the workload and platform level. ## How do Northflank and Fly Sprites compare on pricing? ### Fly Sprites Fly Sprites bills CPU and memory only while a Sprite is active, while persistent storage continues to incur storage charges. Current published rates are $0.07 per CPU-hour and $0.04375 per GB-hour of memory, with storage priced separately. Sprites also offer subscription plans with included usage and concurrency limits. ### Northflank Northflank Cloud charges $0.01667 per vCPU-hour and $0.00833 per GB-hour of memory, billed per second with no seat fees on Pay-as-you-go. Sandboxes use the same resource-based model, while GPU and storage resources are billed separately. At the published rates, Northflank's CPU and memory prices are substantially lower than Sprites'. Northflank also lets teams configure sandbox resources to match the workload rather than using Sprites' fixed 8-vCPU configuration. For teams that need GPUs, supporting application infrastructure, or BYOC, Northflank can also consolidate more of the stack under the same platform. ## When should you choose Northflank vs Fly Sprites? ### Choose Fly Sprites when Fly Sprites fit teams that want persistent Linux environments designed around AI agents and arbitrary code execution. Sprites keep filesystem state across pauses and provide Firecracker isolation, checkpoints, Connectors, and agent-focused tooling. ### Choose Northflank when Northflank fits teams that need production-grade isolated execution as part of a broader platform. Sandboxes can run alongside GPUs, volumes, APIs, workers, jobs, managed databases, previews, and workflows, while Northflank also supports Northflank Cloud, BYOC, and BYOK for customer-controlled infrastructure. | Requirement | Northflank | Fly Sprites | | --- | --- | --- | | **Persistent agent environments** | Persistent volumes when needed | Persistent by default | | **GPU workloads** | GPU-backed Sandboxes and services | Not available | | **Production application stack** | Services, jobs, databases, queues, GPUs, Cloud Harnesses and Sandboxes | Sandbox execution; supporting application infrastructure is separate | | **Full-stack previews** | Native Preview Blueprints | No equivalent native orchestration | | **Customer cloud infrastructure** | BYOC and BYOK | Fly.io managed infrastructure | | **Enterprise governance** | Granular RBAC, SSO, audit logs, and customer-controlled infrastructure | Simpler organisation and API access controls | | **Fits when** | You need isolated execution as part of a broader application and AI platform | You want a persistent Linux environment specifically for agents and code execution | ## Frequently asked questions about Northflank vs Fly Sprites ### What is the main difference between Northflank Sandboxes and Fly Sprites? Fly Sprites are persistent Linux environments built around AI agent and code execution, while Northflank Sandboxes provide isolated execution as part of a broader application and AI infrastructure platform. ### Are Fly Sprites Firecracker-based? Yes. Each Sprite runs in a Firecracker microVM with its own isolated environment. ### Are Northflank Sandboxes persistent? The Sandbox root filesystem is ephemeral by default, but persistent volumes can preserve repositories, models, datasets, and agent state across restarts and scale-to-zero. ### Do Fly Sprites support GPUs? No. Sprites currently provide CPU, memory, and storage resources, without a GPU resource. ### Do Northflank Sandboxes support GPUs? Yes. Northflank supports GPU-backed Sandboxes as well as GPU-enabled services and jobs on supported infrastructure. ### Does Fly Sprites support BYOC? No. Sprites run on Fly.io managed infrastructure. Northflank supports BYOC and BYOK for teams that need workloads on their own cloud or Kubernetes infrastructure. ### Can Northflank replace Fly Sprites? Yes, for teams that need isolated agent execution alongside production services, databases, GPUs, previews, and customer-controlled infrastructure. Northflank also provides Harnesses and Agent Skills for AI coding workflows.

Northflank vs Fly.io: which deployment platform should you choose?

2026-09-18T15:00:00.000Z

## TL;DR: Northflank vs Fly.io - **Fly.io fits developers and teams that need distributed deployments** with Firecracker-based isolation, Anycast routing, and scale-to-zero Machines. Workloads run on Fly.io's managed infrastructure across its global regions, with no BYOC option. - **Northflank fits startups, enterprises, and platform teams that want one self-serve control plane for applications, managed databases, GPU workloads, microVM-backed Sandboxes, and AI coding environments**, with Northflank Cloud, BYOC, and BYOK deployment options across AWS, GCP, Azure, Oracle, CoreWeave, Civo, and Nebius. - **The key difference is infrastructure and workload breadth:** Fly.io is built around globally distributed Machines and direct infrastructure control, while Northflank provides a broader application platform with managed data services, GPUs, isolated execution, and the option to run on Northflank's infrastructure or your own cloud and Kubernetes environments. > [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. > Fly.io is a public cloud for running applications close to users across its regions, with Firecracker microVM isolation, Anycast routing, and Fly Machines that bill by the second and can scale to zero. Northflank is a full-stack deployment and infrastructure platform that combines developer self-service with managed databases, GPU workloads, microVM-backed Sandboxes, AI coding environments, and customer-controlled infrastructure through BYOC and BYOK, alongside a fully managed cloud option. Both platforms support microVM-based workloads, global deployments, and AI agent use cases, but Northflank covers a broader layer of the application stack. Fly.io is built around globally distributed Machines running on Fly infrastructure, while Northflank gives teams a unified platform for services, jobs, databases, GPUs, isolated execution, previews, and infrastructure management across managed cloud and their own cloud environments. This comparison covers deployment models, developer experience, workloads, previews, networking, scaling, observability, security, pricing, and when each platform fits. ## Northflank vs Fly.io: comparison table Product and plan details are current as of September 2026. | Requirement | Northflank | Fly.io | | --- | --- | --- | | **Best for** | Startups, enterprises, platform and AI teams that need governed developer self-service and one control plane across Northflank Cloud, production BYOC, and eligible on-premises or bare-metal Kubernetes | Developers and teams that need multi-region deployments in a managed infrastructure | | **Workloads** | Web and private services, workers, one-off/scheduled/API-triggered jobs, managed databases, caches, queues, persistent volumes, GPU services, and microVM sandboxes | Fly Machines, Fly Managed Postgres, Upstash Redis, Tigris object storage, cron jobs, GPU Machines, and Fly Sprites for AI agent sandboxes | | **Deployment workflow** | Git, Dockerfile, Buildpacks, external images, combined or separate CI/CD, workflows, release pipelines, Templates, GitOps, API, CLI, and SDKs | `fly launch` and `fly deploy` with Dockerfile, Buildpacks, or prebuilt images; `fly.toml`config-as-code; Machines REST API; flyctl CLI; MCP server | | **Infrastructure model** | Kubernetes-based platform across Northflank-managed or customer-controlled infrastructure | Firecracker microVM-based platform on Fly.io's own global infrastructure; no BYOC | | **BYOC targets** | AWS, GCP, Azure, Oracle, CoreWeave, Civo, and Nebius | NA | | **Managed cloud** | Northflank Cloud across global regions | Fly.io infrastructure across global regions | | **BYOK** | On-premises and bare-metal Kubernetes | NA | | **Managed data services** | PostgreSQL, MySQL, MongoDB, Redis, RabbitMQ, and MinIO | Postgres, Upstash Redis, and Tigris object storage | | **GPU workloads** | H100, H200, A100, L4, L40S, and B200 on managed cloud and BYOC GPU node pools | NA | | **Sandboxes** | Kata Containers with Cloud Hypervisor (primary), Firecracker and gVisor depending on workload; available on all cloud targets | Firecracker-based isolation | | **Preview environments** | Full-stack preview blueprints for pull requests, branches, or manual runs, including services, databases, jobs, and volumes | Review apps created through GitHub Actions | | **Multi-region** | 6+ managed cloud regions; 600+ BYOC regions globally | 35+ regions with Anycast BGP and automatic nearest-region routing | | **Private networking** | Private ports, multi-project networking, Tailscale, and port or path policies | WireGuard 6PN mesh, Flycast private proxy, custom private networks for tenant isolation | | **Autoscaling** | CPU, memory, requests per second, or custom Prometheus metrics; BYOC node-pool autoscaling | Proxy-based autostop/autostart and metrics-based Machine autoscaler; scale to zero supported | | **Observability** | Logs and metrics for builds, services, jobs, and addons, plus log sinks | Logs and metrics through Fly platform tooling | | **Security and enterprise** | SOC 2 Type 2 and HIPAA; granular RBAC on all plans, SAML or OIDC SSO, directory sync, scoped API access, multi-level audit logs, and forward-deployed or air-gapped options | SOC 2; HIPAA BAA at $99/month; SSO via Google or GitHub only; scoped macaroon tokens; OIDC for cloud auth | | **Kubernetes** | Core platform across all deployment models | Fly Kubernetes, currently in closed beta | | **Pricing model** | Per-second Northflank Cloud usage with no seat fees; BYOC platform fees plus infrastructure billed directly by the cloud provider | Per-second Machine billing; support tiers from $29/month; HIPAA add-on $99/month; no BYOC | ## What are the deployment models on Northflank and Fly.io? ### Fly.io Fly.io runs workloads on its own infrastructure, with no BYOC option. Its core compute primitive is the Fly Machine, a Firecracker microVM that can be configured by region, resource size, and lifecycle through `fly.toml`, `flyctl`, and the Machines API. Fly.io also provides platform-level networking, routing, TLS termination, and health checks, while Fly Kubernetes (FKS) provides a Kubernetes interface backed by Fly Machines. ### Northflank Northflank provides three deployment models: [Northflank Cloud](https://northflank.com/features/managed-cloud), [BYOC](https://northflank.com/features/bring-your-own-cloud), and [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok). Northflank Cloud provides fully managed infrastructure across global regions, while BYOC provisions Northflank-managed Kubernetes clusters inside your AWS, GCP, Azure, Oracle, CoreWeave, Civo, or Nebius account. BYOK lets teams connect eligible existing Kubernetes clusters across public cloud, on-premises, and bare-metal environments. This gives teams more control over where workloads run without giving up the Northflank developer experience. Teams can start on Northflank Cloud and move to BYOC or BYOK as infrastructure requirements evolve, while retaining the same platform for deployment pipelines, secrets, networking, observability, and application management. ## What is the developer experience like on Northflank and Fly.io? ### Fly.io Fly.io's developer experience centers on **fly launch** and **fly deploy**. fly launch detects the project, generates a fly.toml configuration, and deploys the application, while fly deploy handles subsequent releases. The flyctl CLI provides control over Machines, secrets, logs, volumes, scaling, and SSH access, with the Machines API available for programmatic automation. ### Northflank Northflank provides Git-based deployments with CI and deployment combined by default, while allowing teams to separate them for more granular release workflows. Developers can deploy using Dockerfiles, Buildpacks, or external images, with [Workflows](https://northflank.com/docs/v1/application/release/configure-workflows), [Preview Blueprints](https://northflank.com/docs/v1/application/release/manage-preview-blueprints), [Templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code), [GitOps](https://northflank.com/docs/v1/application/infrastructure-as-code/gitops-on-northflank), APIs, and SDKs supporting more advanced workflows. For AI-assisted development, [Northflank Skills](https://github.com/northflank/skills) let agents such as Claude Code, Codex, Cursor, and OpenCode deploy and manage workloads through the Northflank API and CLI. [Harnesses](https://northflank.com/docs/v1/application/ai-agents/harnesses/quickstart) add dedicated cloud coding environments with isolated resources and networking, giving teams a complete deployment and execution environment for AI coding agents. ## What type of workloads can you run on Northflank and Fly.io? ### Fly.io Fly.io runs containerized workloads as Fly Machines, which can handle web applications, APIs, workers, background processes, and other long-running or one-off workloads. Persistent data can be stored using Fly Volumes, while Fly Managed Postgres, Upstash Redis, and Tigris provide managed data services. For AI workloads, Fly also provides Sprites, persistent Firecracker-based environments designed for running coding agents and other agent workloads. ### Northflank Northflank supports long-running services, workers, one-off and scheduled jobs, managed databases, caches, queues, persistent volumes, GPU workloads, and microVM-backed Sandboxes for isolated execution. Managed data services include PostgreSQL, MySQL, MongoDB, Redis, RabbitMQ, and MinIO, giving teams a broader set of application and data services within the same platform. Northflank also supports GPU workloads on both managed cloud and customer-owned infrastructure, alongside [Sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) for isolated code execution and [Cloud Harnesses](https://northflank.com/docs/v1/application/ai-agents/harnesses/quickstart) for dedicated AI coding environments. This makes Northflank a broader runtime platform for teams that need to run applications, data services, GPUs, and AI workloads together. ## How do previews and private networking work on Northflank and Fly.io? ### Fly.io Fly.io does not provide preview environments as a built-in platform feature. Its documentation provides a GitHub Actions blueprint for creating ephemeral review apps for pull requests, but teams need to configure the workflow themselves. For private networking, Fly.io uses a WireGuard-based 6PN network that connects Machines within an organisation, with `.internal` DNS for service discovery. Flycast provides private access to applications without exposing a public address, while custom private networks can isolate workloads or tenants. ### Northflank Northflank [Preview Blueprints](https://northflank.com/docs/v1/application/release/manage-preview-blueprints) create full-stack preview environments for pull requests, branches, or manual runs. Blueprints can provision services, databases, jobs, volumes, networking, seed workflows, and unique URLs, allowing teams to reproduce an entire application environment automatically for each preview. For private networking, Northflank supports private ports across services, jobs, databases, and addons, along with multi-project networking, [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies), egress controls, Tailscale integration, IP policies, and path-level security rules. ## How do scaling, observability, and resource controls work on Northflank and Fly.io? ### Fly.io Fly.io provides two main autoscaling approaches. Proxy-based autostop/autostart stops idle Machines and starts them when traffic returns, while the metrics-based autoscaler can create or remove Machines based on workload metrics. This supports both scale-to-zero workloads and applications that need Machines added or removed based on demand. Fly.io also provides application and infrastructure observability through Prometheus and Grafana, live logs with `fly logs`, searchable log history, and log export integrations. Developers can monitor Machines and workloads directly through Fly's tooling. ### Northflank Northflank [autoscaling](https://northflank.com/docs/v1/application/scale/autoscale-deployments) supports CPU, memory, requests per second, and custom Prometheus metrics, with configurable minimum and maximum instance counts. BYOC adds infrastructure-level controls including node-pool autoscaling, spot capacity, workload affinity, and build placement, while custom resource plans let platform teams standardize compute resources across workloads. Northflank provides logs and metrics for builds, deployments, jobs, and addons through the platform and API. [Log sinks](https://northflank.com/docs/v1/application/observe/configure-log-sinks) let teams forward logs to external providers, Amazon S3, and HTTP endpoints, making it easier to integrate Northflank into an existing observability stack. ## Which security and enterprise controls do Northflank and Fly.io provide? ### Fly.io Fly.io is SOC 2 compliant, with HIPAA BAA support available as a $99/month add-on. SSO is supported through Google and GitHub, while scoped macaroon tokens provide expiring API credentials for CI/CD. Fly.io's organisation RBAC has two roles: Member and Admin. For teams that need granular project or resource permissions, or enterprise identity providers such as Okta and Entra ID, Fly.io's built-in controls are more limited and may require additional tooling. ### Northflank Northflank is SOC 2 Type 2 and HIPAA compliant, with Enterprise BAAs. [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control) provides granular permissions across organisations, teams, projects, and resources, while [SAML or OIDC SSO](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication) and directory sync support enterprise identity providers. Audit logs provide visibility across organisation and resource activity and can be exported to SIEM systems. [Northflank Enterprise](https://northflank.com/enterprise) adds contractual uptime guarantees, engineering support, custom disaster recovery, and forward-deployed or air-gapped control plane options for regulated environments. For enterprises with strict identity, governance, or infrastructure requirements, Northflank provides a broader set of controls without requiring teams to build the missing pieces around the platform. ## How do Northflank and Fly.io compare on pricing and total cost of ownership? ### Fly.io Fly.io bills infrastructure based on the resources your applications provision, with Machine compute billed by the second. A `shared-cpu-1x` Machine with 256 MB RAM costs approximately **$1.94 per month** when running continuously, while storage, network transfer, and Managed Postgres are billed separately. Fly.io also offers optional paid support from $29 per month and a $99 per month Compliance add-on. ### Northflank Northflank Cloud charges $0.01667 per vCPU-hour and $0.00833 per GB-hour, billed per second with no seat fees on Pay-as-you-go. The free Sandbox tier includes two services, one database, and two cron jobs. With BYOC, Northflank charges $0.01389 per vCPU-hour and $0.00139 per GB-hour. At the same time, your cloud provider bills the underlying infrastructure directly, allowing teams to retain applicable cloud credits, commitments, and negotiated rates. Northflank can be significantly cheaper for teams running multiple workloads because there is no separate platform or seat charge on Pay-as-you-go. Its pricing also covers a broader application platform, including services, jobs, databases, previews, autoscaling, and observability, while BYOC lets teams use their existing cloud infrastructure and pricing agreements. For total cost of ownership, compare compute, storage, databases, networking, previews, GPUs, and any additional support or infrastructure costs across both platforms. ## When should you choose Northflank vs Fly.io? | Requirement | Northflank | Fly.io | | --- | --- | --- | | **Infrastructure ownership** | Northflank Cloud, BYOC across multiple cloud providers, or BYOK for eligible Kubernetes clusters | All workloads run on Fly.io infrastructure; no BYOC | | **Multi-region deployments** | Global managed cloud regions, plus customer-selected regions through BYOC | 35+ global regions with Anycast routing | | **Application platform** | Services, workers, jobs, databases, GPUs, Sandboxes, and Cloud Harnesses | Fly Machines, persistent volumes, Managed Postgres, and Sprites | | **Managed data services** | PostgreSQL, MySQL, MongoDB, Redis, RabbitMQ, and MinIO | Managed Postgres, Upstash Redis, and Tigris object storage | | **AI agent workloads** | MicroVM-backed Sandboxes, Cloud Harnesses, Agent Skills, and GPU workloads | Sprites and Fly Machines with Firecracker isolation | | **Preview environments** | Full-stack Preview Blueprints built into the platform | Review apps through GitHub Actions | | **Enterprise governance** | Granular RBAC, SAML/OIDC SSO, audit logs, BYOC/BYOK, and forward-deployed or air-gapped options | Organisation roles, SSO, scoped tokens, and hardware isolation | | **Data residency** | Run workloads in Northflank Cloud or your own cloud and Kubernetes infrastructure | Workloads run on Fly.io infrastructure | | **Pricing** | Per-second usage with no seat fees on Pay-as-you-go; BYOC uses your existing cloud infrastructure | Per-second Machine billing plus storage, networking, and managed service costs | | **Best fit** | Teams that need a broader platform for applications, data, GPUs, AI workloads, and customer-controlled infrastructure | Developers who prioritise globally distributed applications and direct control over Fly Machines | ## FAQs: Northflank vs Fly.io ### Is Northflank better than Fly.io? Northflank is built for teams that need broader infrastructure options, including managed databases, GPUs, Sandboxes, BYOC, BYOK, and enterprise controls. Fly.io focuses on globally distributed applications running on its own infrastructure. ### Does Fly.io support BYOC? No. Fly.io workloads run on Fly.io's infrastructure, while Northflank supports BYOC across multiple cloud providers and BYOK for eligible Kubernetes clusters. ### How do Northflank and Fly.io compare on databases? Fly.io provides Managed Postgres, Upstash Redis, and Tigris, while Northflank provides PostgreSQL, MySQL, MongoDB, Redis, RabbitMQ, and MinIO as managed platform services. ### Which platform is better for enterprise teams? Northflank provides granular RBAC, SAML/OIDC SSO, audit logs, BYOC/BYOK, and forward-deployed or air-gapped deployment options for enterprise environments.

Northflank vs Qovery: which platform fits your requirements?

2026-09-17T15:45:00.000Z

## TL;DR: Northflank vs Qovery - **Qovery fits small teams with no DevOps experience** that want a self-service platform for Kubernetes running in their own AWS, GCP, Azure, or Scaleway account, with managed cluster operations, built-in CI/CD, preview environments, and observability. - **Northflank fits startups, enterprises, and platform teams** that want one self-serve platform for application deployment, managed databases, GPU workloads, microVM-backed Sandboxes, Harnesses, preview environments, and customer-controlled infrastructure, with managed cloud, BYOC (AWS, GCP, Azure, Oracle, CoreWeave, Civo, and Nebius), and BYOK deployment options. - **Northflank is a broader runtime platform for AI-native workloads**, combining application infrastructure with GPUs, Sandboxes, databases, and AI coding environments instead of focusing primarily on the Kubernetes application layer. > [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. > Qovery is a Kubernetes control plane for teams that want self-service infrastructure on their own AWS, GCP, Azure, or Scaleway account, with built-in deployment pipelines. Northflank is a full-stack deployment and infrastructure platform that combines developer self-service with managed data services, microVM sandboxes, GPU workloads, and BYOC across a broader set of cloud providers and infrastructure targets. Both platforms eliminate the need to operate Kubernetes directly and support AI coding agent workflows. The differences are in infrastructure scope, workload types, pricing model, and how much of the operational layer each platform manages for you. This comparison covers deployment models, developer experience, workloads, previews, networking, scaling, observability, security, pricing, and when each platform fits. ## Northflank vs Qovery: comparison table Product and plan details are current as of September 2026. | Requirement | Northflank | Qovery | | --- | --- | --- | | **Best for** | Startups, enterprises, platform and AI teams that need governed developer self-service and one control plane across Northflank Cloud, production BYOC, eligible on-premises or bare-metal Kubernetes | Teams with small or no DevOps teams that want self-service Kubernetes in their own cloud account with a flat monthly pricing ($3,749/month excluding add-ons) | | **Workloads** | Web and private services, workers, one-off/scheduled/API-triggered jobs, managed databases, caches, queues, persistent volumes, GPU services, and microVM sandboxes | Applications, containers, Helm charts, Terraform modules, cron jobs, and lifecycle jobs. | | **Deployment workflow** | Git, Dockerfile, Buildpacks, external images, combined or separate CI/CD, workflows, release pipelines, Templates, GitOps, API, CLI, SDKs and Agent Skills | Git auto-deploy, Dockerfile, containers, Helm charts, Terraform, deployment pipelines with stages, CLI, Terraform provider, API, and MCP server | | **Infrastructure model** | Kubernetes-based platform across Northflank-managed or customer-controlled infrastructure | BYOC Kubernetes in your AWS, GCP, Azure, or Scaleway account; no managed cloud option | | **BYOC targets** | AWS, GCP, Azure, Oracle, CoreWeave, Civo, and Nebius | AWS, GCP, Azure, and Scaleway | | **Managed cloud** | Northflank Cloud across 6+ regions | Not available | | **BYOK** | On-premises and bare-metal Kubernetes | Yes (Bring Your Own Kubernetes) | | **Managed data services** | PostgreSQL, MySQL, MongoDB, Redis, RabbitMQ, and MinIO | Cloud-native database services in your own account (RDS, CloudSQL, etc.) | | **GPU workloads** | Managed-cloud GPU plans and GPU node pools in BYOC | GPU instances in your cloud | | **Sandboxes** | Kata Containers with Cloud Hypervisor (primary), Firecracker and gVisor depending on workload | Not available | | **Preview environments** | Full-stack preview blueprints for pull requests, branches, or manual runs, including services, databases, jobs, and volumes | Ephemeral preview environments with deployment rules for auto-sleep and teardown | | **Private networking** | Private ports, multi-project networking, Tailscale, and port or path policies | VPC peering, egress filtering via proxy, NGINX API gateway | | **Autoscaling** | CPU, memory, requests per second, or custom Prometheus metrics; BYOC node-pool autoscaling | Kubernetes HPA and Karpenter for node-level autoscaling | | **Observability** | Logs and metrics for builds, services, jobs, and addons, plus log sinks | Application logs and live metrics built in; full observability via Observe bundle ($299/cluster/month add-on) | | **Secret management** | Northflank secret groups | AWS Secrets Manager, AWS Parameter Store, GCP Secret Manager, Doppler integrations | | **Security and enterprise** | SOC 2 Type 2 and HIPAA; granular RBAC, SAML or OIDC SSO, directory sync, scoped API access, multi-level audit logs, and forward-deployed or air-gapped options | SOC 2 Type II and GDPR (Business); HIPAA, HDS, ISO 27001, DORA, SSO, unlimited RBAC, custom audit retention, and air-gapped control plane on Enterprise | | **AI agent support** | Northflank Skills for Claude Code, Codex, Cursor, and OpenCode; Harnesses for AI coding agent environments | MCP server, AI Copilot, and agent skills | | **Pricing model** | Per-second Northflank Cloud usage with no seat fees; BYOC platform fees plus infrastructure billed by the cloud provider | Flat per-organization monthly pricing: Business from $3,749/month, or $2,999/month billed annually (20 users, up to 3 clusters) | ## What are the deployment models on Northflank and Qovery? ### Qovery Qovery is BYOC-only. It provisions and manages Kubernetes clusters in your own AWS, GCP, Azure, or Scaleway account. There is no Qovery-managed cloud option where Qovery hosts your infrastructure; your applications always run in your own cloud account, on infrastructure you own. Qovery also supports BYOK, allowing teams to connect an existing Kubernetes cluster on Enterprise. ### Northflank Northflank provides three deployment models: [Northflank Cloud](https://northflank.com/features/managed-cloud), [BYOC](https://northflank.com/features/bring-your-own-cloud), and [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok). Northflank Cloud provides fully managed infrastructure across 6+ regions for teams that do not want to manage cloud accounts. BYOC provisions Northflank-managed Kubernetes clusters in your own cloud account across AWS, GCP, Azure, Oracle, CoreWeave, Civo, and Nebius. BYOK connects eligible existing Kubernetes clusters from public clouds, on-premises, and bare-metal. Teams can start on Northflank Cloud and move to BYOC without changing their deployment workflow. The same control plane, developer interface, and governance controls apply across all three models. ## What is the developer experience like on Northflank and Qovery? ### Qovery Qovery provides a self-service console where developers deploy applications by connecting a Git repository, selecting a service type, and triggering deployments without writing Kubernetes manifests. Deployment pipelines with stages allow platform teams to orchestrate ordered rollouts across services. Its MCP server lets AI coding agents such as Claude Code, Codex, Gemini CLI, and Cursor deploy and manage infrastructure through the Qovery API. ### Northflank Northflank provides self-service Git-based deployments with CI and deployment combined by default, with the option to separate them for more granular release workflows. Developers can deploy using Dockerfiles, Buildpacks, or external images. [Workflows](https://northflank.com/docs/v1/application/release/configure-workflows), [preview blueprints](https://northflank.com/docs/v1/application/release/manage-preview-blueprints), [Templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code), and [GitOps](https://northflank.com/docs/v1/application/infrastructure-as-code/gitops-on-northflank) support more complex release and infrastructure workflows. The SDKs enable programmatic control beyond the dashboard and CLI. [Northflank Skills](https://github.com/northflank/skills) enable AI coding agents in Claude Code, Codex, Cursor, and OpenCode to deploy and manage workloads via the Northflank API and CLI. [Northflank Harnesses](https://northflank.com/docs/v1/application/cloud-harness/quickstart) provide dedicated cloud coding environments where AI coding agents run in isolated, secure environments with their own resources and networking. ## What type of workloads can you run on Northflank and Qovery? ### Qovery Qovery supports application deployments, containers, Helm charts, Terraform modules, cron jobs, and lifecycle jobs. For data services, Qovery provisions cloud-native managed databases in the customer's cloud account, such as AWS RDS and Google Cloud SQL. Northflank provides managed database and stateful services directly through the Northflank platform alongside application workloads. Qovery supports GPU workloads through GPU-enabled Kubernetes infrastructure in the customer's cloud, but does not provide an equivalent to Northflank's microVM Sandbox product for isolated code or agent execution. ### Northflank Northflank supports long-running services, workers, one-off and scheduled jobs, managed databases and caches (PostgreSQL, MySQL, MongoDB, Redis, RabbitMQ, MinIO) as first-class platform services, GPU workloads (H100, H200, A100, L4, L40S, B200), and microVM-isolated sandboxes for AI agent execution and untrusted code. Northflank also provides [Harnesses](https://northflank.com/docs/v1/application/cloud-harness/quickstart) dedicated cloud environments for AI coding agents. Managed data services on Northflank run alongside application services in the same project, connected through internal private networking. There is no public endpoint required and no separate database billing relationship. The sandbox isolation model is a meaningful difference for teams running AI agent workloads. Northflank sandboxes use Kata Containers with Cloud Hypervisor as the primary microVM approach, providing kernel-level isolation. Qovery does not have an equivalent sandbox product. ## How do previews and private networking work on Northflank and Qovery? ### Qovery Qovery provides ephemeral preview environments that can be created from existing environments and managed with deployment rules. Teams can automatically sleep environments during specified periods and tear them down when they are no longer needed, helping control the infrastructure used by temporary environments. For networking, Qovery provides private connectivity through the cloud and Kubernetes infrastructure where its environments run. It supports options such as VPC peering, egress filtering, and Kubernetes-level network controls for managing how applications communicate with external and internal services. ### Northflank Northflank [Preview Blueprints](https://northflank.com/docs/v1/application/release/manage-preview-blueprints) create complete, repeatable preview environments from pull requests, branches, or manual runs. A blueprint can define the services, databases, jobs, volumes, networking, and configuration required for the environment, so teams can reproduce a full application stack rather than previewing a single service. Preview environments can also use isolated database instances and seed workflows, allowing teams to test against preview-specific data instead of sharing a staging database. This makes full-stack previews practical for applications with multiple services and stateful dependencies. For networking, Northflank provides private ports across services, jobs, databases, and addons, along with [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies), egress controls, multi-project networking, Tailscale integration, IP policies, and path-level security rules. This gives platform teams control over how workloads communicate with each other, what they can access externally, and how private services are exposed. ## How do scaling, observability, and resource controls work on Northflank and Qovery? ### Qovery Qovery uses Kubernetes Horizontal Pod Autoscaling to scale applications based on CPU or custom metrics, while Karpenter can automatically scale nodes on Qovery-managed clusters based on workload demand. Teams can also define resource requests and limits for applications and jobs. Application logs and live metrics are included in the base plan. Deeper infrastructure observability is available through the Observe add-on at $299 per cluster per month, which adds Kubernetes events, infrastructure metrics, and additional monitoring. ### Northflank Northflank supports workload-level autoscaling based on CPU, memory, requests per second, or custom Prometheus metrics, with configurable minimum and maximum instance counts. Teams can also adjust CPU and memory allocations for individual workloads. For BYOC environments, Northflank extends these controls to infrastructure with multiple node pools, different node types, availability zones, workload placement rules, and spot instances. Custom resource plans can also standardize CPU and memory limits across workloads. Northflank provides logs and metrics for builds, deployments, jobs, addons, and cluster resources. [Log sinks](https://northflank.com/docs/v1/application/observe/configure-log-sinks) can forward logs to external observability platforms and storage systems. ## Which security and enterprise controls do Northflank and Qovery provide? ### Qovery Qovery Business includes SOC 2 Type II and GDPR compliance, built-in RBAC roles, and 30-day audit log retention. Enterprise adds SSO, unlimited custom RBAC roles, policy-as-code guardrails, custom audit log retention, access to security audits and pentests, and compliance packages covering HIPAA, HDS, ISO 27001, and DORA. Enterprise also supports a self-hosted control plane that can run air-gapped. Qovery also provides API Policy Tokens for agents and automation. These use OPA and Rego to scope tokens to specific actions and resources, with token activity attributed separately in the audit log. ### Northflank Northflank is SOC 2 Type 2 and HIPAA compliant, with Business Associate Agreements available under Enterprise contracts. RBAC provides granular permissions across organisations, teams, projects, and resources, while SAML/OIDC SSO and directory sync provide centralised identity management for Enterprise customers. Audit logs can be exported to SIEM systems. Northflank Enterprise adds contractual SLAs, direct engineering support, advanced disaster recovery, and a forward-deployed control plane that can run inside a customer-controlled VPC or data centre, including zero-egress and air-gapped environments. ## How do Northflank and Qovery compare on pricing and total cost of ownership? ### Qovery Qovery uses flat per-organisation pricing. The Business plan costs $3,749 per month(or $2,999/month billed annually) and includes 20 users, up to 3 managed clusters, and 10,000 deployment minutes per month. Additional clusters cost $399 per month, custom builder size costs $150 per month, while deployment minutes above the included 10,000 are billed at $0.16 per minute. The Observe bundle is a $299 per-cluster monthly add-on, and Enterprise pricing is custom. The underlying cloud infrastructure is billed directly by your cloud provider because Qovery runs workloads in your cloud account. This means the platform subscription and infrastructure costs are separate. ### Northflank Northflank Cloud uses usage-based pricing at $0.01667 per vCPU-hour and $0.00833 per GB-hour of memory, billed per second with no seat fees on Pay-as-you-go. The free Sandbox tier also includes two services, one database, and two cron jobs with always-on compute. For BYOC, Northflank charges $0.01389 per vCPU-hour and $0.00139 per GB-hour of memory, while your cloud provider bills the underlying infrastructure directly. This lets teams retain existing cloud credits, commitments, and negotiated infrastructure pricing. For many teams, Northflank can be significantly cheaper because you are not paying a $3,749 ****monthly platform fee just to use the platform. Northflank's per-second billing and no-seat-fee model also means smaller, variable, or growing workloads can be priced much more directly around actual resource consumption. With BYOC, teams can further reduce infrastructure costs by using their existing cloud commitments, spot capacity, and resource controls. ## When should you choose Northflank vs Qovery? | Requirement | Northflank | Qovery | | --- | --- | --- | | **Cloud infrastructure** | Best if you need managed cloud, BYOC across more providers, or BYOK for eligible existing Kubernetes | Best if you want BYOC in AWS, GCP, Azure, or Scaleway with flat monthly pricing | | **Application workloads** | Services, jobs, GPUs, microVM sandboxes, Harnesses, and broader workload types | Applications, Helm charts, Terraform, cron jobs, and lifecycle jobs | | **Data services** | Managed PostgreSQL, MySQL, MongoDB, Redis, RabbitMQ, and MinIO alongside application services | Cloud-native databases in your own account | | **GPU workloads** | H100, H200, A100, L4, L40S, and B200 on managed cloud and BYOC | GPU instances in your cloud | | **Sandbox isolation** | MicroVM-based sandboxes with kernel-level isolation for AI agents and untrusted code | Not available | | **Observability** | Logs and metrics included; log sinks to external providers | Application logs and metrics included; full observability at $299/cluster/month | | **Pricing model** | Per-second usage with no seat fees; BYOC platform fees plus cloud provider costs | Flat per-organization monthly pricing from $3,749/month | | **Enterprise requirements** | SOC 2, HIPAA, granular RBAC, SSO, directory sync, audit logs, BYOC/BYOK, and forward-deployed or air-gapped options | SOC 2, GDPR, HIPAA, HDS, ISO 27001, DORA, SSO, policy-as-code, and air-gapped control plane on Enterprise | | **AI agent workflows** | Harnesses, and agent Skills for Claude Code, Codex, Cursor, and OpenCode | MCP server, and agent skills for Claude Code, Codex, Gemini CLI, Cursor | | **Best fit** | Teams that need broader self-service infrastructure options, managed data services, GPU workloads, and microVM sandboxes | Teams that want self-service Kubernetes in their own cloud with flat pricing | [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## FAQs: Northflank vs Qovery ### Is Northflank better than Qovery? It depends on your infrastructure needs, but Northflank offers a broader platform for teams running applications, managed databases, GPUs, microVM sandboxes, and AI workloads. It also supports Northflank Cloud, BYOC, and BYOK with per-second usage pricing. ### How do Northflank and Qovery compare on pricing? Qovery starts at $3,749/month for Business, plus cloud infrastructure and optional add-ons. Northflank uses per-second usage pricing with no seat fees, which can make it significantly cheaper for teams with smaller, variable, or growing workloads. ### Which is better for database support? Northflank provides managed PostgreSQL, MySQL, MongoDB, Redis, RabbitMQ, and MinIO as first-class platform services. This makes it easy to provision databases alongside your applications without managing separate cloud database infrastructure. ### Which platform is better for AI agent workloads? Northflank is built for AI-native workloads, with GPUs, microVM-backed Sandboxes for isolated execution, and Harnesses for dedicated AI coding environments. It also supports Claude Code, Codex, Cursor, and OpenCode through Northflank Skills.

Northflank vs Porter: which platform fits your requirements?

2026-09-15T16:15:00.000Z

## TL;DR: Northflank vs Porter - **Porter fits smaller teams and relatively simple workloads that want a Kubernetes abstraction layer in their own cloud.** It provides managed Kubernetes operations, Git-based deployments, autoscaling, GPUs, and preview environments across AWS, GCP, and Azure. - **Northflank fits teams, enterprises, and platform teams running more complex workloads and infrastructure.** It combines a simple developer experience with services, jobs, managed databases, GPUs, Sandboxes, preview environments, BYOC and BYOK, giving teams a single control plane as their applications and infrastructure grow in complexity. - **Northflank supports more deployment and infrastructure options.** Teams can use [Northflank Cloud](https://northflank.com/features/managed-cloud), deploy to their own [AWS, GCP, or Azure infrastructure with BYOC](https://northflank.com/features/bring-your-own-cloud), or connect eligible existing [Kubernetes clusters with BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok). > [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. > Porter is a Kubernetes-based PaaS that provisions and manages infrastructure in your AWS, GCP, or Azure account, abstracting cluster operations while keeping cloud ownership with you. Northflank is a full-stack deployment and infrastructure platform that combines developer self-service with production workloads, managed data services, Sandboxes, GPU workloads, and BYOC across multiple cloud providers and infrastructure targets. Both reduce the operational burden of Kubernetes, but they scope that abstraction differently and serve different infrastructure requirements. This comparison covers deployment models, developer experience, workloads, preview environments, networking, scaling, observability, security, pricing, and when each platform fits. ## Northflank vs Porter: comparison table Product and plan details are current as of September 2026. | Requirement | Northflank | Porter | | --- | --- | --- | | **Best for** | Startups, enterprises, platform and AI teams that need governed developer self-service experience and one control plane across Northflank Cloud, production BYOC, eligible on-premises or bare-metal Kubernetes. | Startups and small teams with relatively simple workloads that want Kubernetes power in their own AWS, GCP, or Azure account with automatic cluster management | | **Workloads** | Web and private services, workers, one-off/scheduled/API-triggered jobs, managed databases, caches, queues, persistent volumes, GPU services, and microVM sandboxes | Web services, workers, cron jobs, and container jobs | | **Deployment workflow** | Git, Dockerfile, Buildpacks, external images, combined or separate CI/CD, workflows, release pipelines, Templates, GitOps, API, CLI, and JavaScript client | Git via GitHub Actions, Dockerfile or Buildpacks, external images, `porter.yaml`config-as-code, API, CLI, and MCP server | | **Infrastructure model** | Kubernetes-based platform across Northflank-managed or customer-controlled infrastructure | Kubernetes cluster provisioned and managed in your AWS, GCP, or Azure account | | **BYOC targets** | AWS, GCP, Azure, Oracle, CoreWeave, Civo, and Nebius | AWS, GCP, and Azure | | **Managed cloud** | Northflank Cloud across 6+ regions | NA | | **BYOK** | On-premises and bare-metal Kubernetes | NA | | **Managed Data services** | PostgreSQL, MySQL, MongoDB, Redis, RabbitMQ, and MinIO | Postgres and Redis in your cloud (AWS-only) | | **GPU workloads** | Managed-cloud GPU plans and GPU node pools in BYOC | GPU instances in your cloud | | **Sandboxes** | Kata Containers with Cloud Hypervisor (primary), Firecracker and gVisor depending on workload, provider, region, and infrastructure | Container-based isolated workloads; AWS only (private beta) | | **Preview environments** | Full-stack preview blueprints for pull requests, branches, or manual runs, including services, databases, jobs, and volumes | Per-PR preview environments for applications | | **Private networking** | Private ports, multi-project networking, Tailscale, and port or path policies | VPC-native private networking within the provisioned cluster | | **Autoscaling** | CPU, memory, requests per second, or custom Prometheus metrics; BYOC node-pool autoscaling and scheduling controls | HPA-based autoscaling plus Karpenter for node-level bin-packing and cost optimization | | **Observability** | Logs and metrics for builds, services, jobs, and addons, plus log sinks and API access | Dashboard logs, metrics, Datadog, New Relic, and Grafana add-ons | | **Security and enterprise** | SOC 2 Type 2 and HIPAA compliance; granular RBAC, SAML or OIDC SSO, directory sync, scoped API access, multi-level audit logs, and forward-deployed or air-gapped options | SOC 2 Type II and HIPAA (AWS-only); Advanced RBAC and SAML SSO on Enterprise | | **Customer VPC deployments** | Yes — SaaS fleet management into customer cloud accounts | Yes — deploy directly into customer VPCs | | **Pricing model** | Per-second Northflank Cloud usage; BYOC platform fees plus infrastructure billed directly by the cloud provider | Per-resource metered billing ($6/GB RAM/month, $13/vCPU/month) plus cloud provider costs | ## What are the deployment models on Northflank and Porter? Northflank and Porter both support running workloads on Kubernetes, but they take different approaches to infrastructure ownership and deployment. Understanding these models helps determine which platform fits your existing cloud infrastructure and operational requirements. ### Porter Porter uses a BYOC model where it provisions and manages a Kubernetes cluster in your AWS, GCP, or Azure account. After you connect your cloud credentials, Porter manages the Kubernetes layer, including cluster upgrades, security patches, and node management, while the underlying cloud infrastructure remains in your account. Porter is therefore designed for teams that want the benefits of a PaaS while keeping their applications and Kubernetes infrastructure in their own cloud environment. ### Northflank Northflank provides three deployment models: [**Northflank Cloud**](https://northflank.com/features/managed-cloud), [**BYOC**](https://northflank.com/features/bring-your-own-cloud), and [**BYOK**](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok). Northflank Cloud provides fully managed infrastructure, while BYOC lets teams provision Northflank-managed Kubernetes clusters in their own cloud infrastructure. BYOK lets teams connect eligible existing Kubernetes clusters across supported public clouds, on-premises, and bare-metal infrastructure. Northflank BYOC supports AWS, GCP, Azure, Oracle Cloud, CoreWeave, Civo, and Nebius, giving teams more options for where their workloads run. ## What is the developer experience like on Northflank and Porter? Both platforms provide a PaaS-style developer experience that abstracts Kubernetes and lets teams deploy applications from Git without managing Kubernetes manifests directly. The difference is in the deployment workflows, configuration options, and developer tooling each platform provides. ### Porter Porter lets developers connect a GitHub repository, select a workload type such as a web service, worker, or job, and deploy through the Porter dashboard. Teams can use `porter.yaml` for version-controlled application configuration, while the Porter CLI provides a terminal-based workflow. Porter's MCP server also lets compatible AI coding agents deploy, inspect, and manage applications. ### Northflank Northflank provides Git-based deployments with CI and deployment combined by default, while giving teams the option to separate them for more granular release workflows. Developers can deploy using Dockerfiles, Buildpacks, or external images, while Workflows, Templates, and GitOps provide additional control for more complex applications and infrastructure. The platform also supports preview environments, API and CLI access, and Northflank Skills for deploying and managing workloads through compatible AI coding agents. ## What type of workloads can you run on Northflank and Porter? Both Northflank and Porter support a range of workloads beyond standard web applications, including services, workers, jobs, GPUs, and isolated environments for AI workloads. The main difference is the breadth of workloads and managed infrastructure available through each platform. ### Porter Porter supports web services, private services, workers, cron jobs, and container jobs, with GPU infrastructure available for training and inference workloads. Its Sandboxes (private beta and AWS-only) provide isolated environments for use cases such as code execution and AI agent workloads, while add-ons extend the platform with services such as PostgreSQL and Redis. ### Northflank Northflank supports long-running services, workers, one-off and scheduled jobs, managed databases and caches, GPU services and jobs, and isolated Sandboxes for AI agents and untrusted code execution. Managed data services include PostgreSQL, MySQL, MongoDB, Redis, RabbitMQ, and MinIO, while GPU workloads can run alongside the rest of the application stack in Northflank Cloud or BYOC environments. Northflank also provides Harnesses, dedicated cloud environments for AI coding agents and interactive development workflows. ## How do previews and private networking work on Northflank and Porter? Both Northflank and Porter support preview environments and private networking, but Northflank provides more flexibility for creating complete, isolated application environments and controlling how workloads communicate. ### Porter Porter can generate a preview environment for each pull request, deploying a copy of the application using the same build and deployment configuration. Preview environments run on the existing Kubernetes cluster in the customer's cloud account. For private networking, Porter uses the VPC-native networking of the provisioned Kubernetes cluster, allowing services within the cluster to communicate over internal networking. ### Northflank Northflank Preview Blueprints create full-stack preview environments for pull requests, branches, or manual runs. A blueprint can include services, databases, jobs, volumes, networking, seed workflows, and unique URLs, with database instances that can be forked from staging backups so each preview can have its own isolated data. For private networking, Northflank supports private ports across services, jobs, databases, and addons, along with multi-project networking, network policies, egress controls, Tailscale integration, IP policies, and path-level security rules. ## How do scaling, observability, and resource controls work on Northflank and Porter? Both Northflank and Porter provide autoscaling, resource controls, and built-in observability, while giving platform teams additional controls over the underlying Kubernetes infrastructure. ### Porter Porter uses the Kubernetes HPA for workload scaling and Karpenter for node-level autoscaling and bin-packing. Karpenter can right-size node capacity, consolidate underutilized nodes, and use spot instances where configured, helping teams optimize infrastructure costs as workloads change. Porter also provides dashboard logs and metrics, with integrations for observability platforms such as Datadog, New Relic, and Grafana, as well as LLM-specific tools including Langfuse and Helicone. ### Northflank Northflank supports autoscaling based on CPU, memory, requests per second, and custom Prometheus metrics. BYOC deployments add node-pool autoscaling, spot capacity, workload affinity, and build placement controls, while custom resource plans let platform teams define standardized compute tiers that developers can select without managing raw infrastructure settings. Northflank also provides logs and metrics for builds, deployments, jobs, and addons through the UI and API, with log sinks for routing logs to external providers, Amazon S3, or HTTP endpoints. ## Which security and enterprise controls do Northflank and Porter provide? Both Northflank and Porter provide enterprise security controls for teams running production workloads, including RBAC, SSO, audit logging, and compliance features. The main difference is how granular those controls are and the infrastructure options available for organizations with stricter isolation or deployment requirements. ### Porter Porter is SOC 2 Type II certified and provides HIPAA-compliant infrastructure support on AWS, with enterprise features including Advanced RBAC, SAML-based SSO, custom alerts, and on-premises installation. Because Porter runs Kubernetes in the customer's AWS, GCP, or Azure account, teams can also use their existing cloud IAM, networking, and security controls alongside Porter. Porter disclosed a [security incident in April 2026 involving a stale AWS access key](https://news.ycombinator.com/item?id=47811132) that affected 21 customer cloud accounts, exposing some secrets and credentials. Porter subsequently revoked the affected credentials and implemented additional security controls. This incident is worth considering when evaluating the security architecture and access model of any platform that manages infrastructure in your cloud account. ### Northflank Northflank is SOC 2 Type 2 and HIPAA compliant, with Enterprise BAAs. Its RBAC provides granular permissions across organizations, teams, projects, and resources, while SAML or OIDC SSO and directory sync centralize identity management. Audit logs provide visibility across organization and resource activity, with options to export logs to external systems. For enterprise environments, Northflank also supports customer-controlled infrastructure through BYOC and BYOK, alongside forward-deployed and air-gapped control plane options for environments with stricter connectivity and isolation requirements. ## How do Northflank and Porter compare on pricing and total cost of ownership? Both platforms use usage-based pricing, but the infrastructure costs are structured differently. Porter charges for the resources your applications request and adds the underlying AWS, Azure, or GCP infrastructure costs. Northflank offers both managed-cloud pricing and BYOC pricing, giving teams a choice between paying Northflank for infrastructure or keeping the underlying cloud bill in their own account. ### Porter Porter's Standard plan charges $0.019 per vCPU-hour and $0.009 per GB of RAM-hour, with the platform fee billed separately from the underlying AWS, Azure, or GCP infrastructure. Porter also offers volume discounts on Enterprise plans starting at 40 vCPU and 80 GB of RAM. Cloud credits can be used to cover the underlying cloud provider costs. ### Northflank Northflank Cloud charges $0.01667 per vCPU-hour and $0.00833 per GB-hour, billed per second with no seat fees on Pay-as-you-go. [The free Sandbox tier](https://northflank.com/pricing) includes two services, one database, and two cron jobs with always-on compute. For BYOC, Northflank charges $0.01389 per vCPU-hour and $0.00139 per GB-hour, while the underlying cloud infrastructure is billed directly by the cloud provider. This lets teams continue using existing cloud credits, commitments, and negotiated infrastructure rates. Pricing alone does not determine total cost of ownership. For a meaningful comparison, evaluate a representative workload topology including compute, storage, data services, network egress, preview environments, GPU usage, infrastructure utilization, and the operational overhead associated with managing the platform. ## When should you choose Northflank vs Porter? The right choice depends on your infrastructure model, workload requirements, and how much platform control your team needs. Porter focuses on simplifying Kubernetes in your AWS, GCP, or Azure account, while Northflank supports a broader range of infrastructure, workloads, and enterprise requirements. More and more teams are moving from Porter to Northflank as their workloads and infrastructure requirements become more complex. Northflank provides the same self-service developer experience while giving these teams more options for workloads, managed data, GPUs, sandboxing, infrastructure, and platform governance. | Requirement | Porter | Northflank | | --- | --- | --- | | **Cloud infrastructure** | Best if you want to run in your own AWS, GCP, or Azure account | Best if you need managed cloud, BYOC across more cloud providers, or BYOK for eligible existing Kubernetes | | **Application workloads** | Web services, workers, jobs, and GPU workloads | Services, jobs, GPUs, Sandboxes, Harnesses, and broader application workloads | | **Data services** | Postgres and Redis on AWS | PostgreSQL, MySQL, MongoDB, Redis, RabbitMQ, and MinIO | | **Kubernetes operations** | Good if you want Porter to provision and manage Kubernetes in your cloud | Good if you want Kubernetes abstracted across Northflank Cloud, BYOC, or BYOK | | **AI and sandbox workloads** | Container-based Sandboxes on AWS, currently in private beta | MicroVM-based Sandboxes plus Harnesses for AI agents and untrusted code | | **Enterprise requirements** | SAML SSO, Advanced RBAC, custom alerts, and on-premises installation on Enterprise | Granular RBAC, SSO, directory sync, audit logs, BYOC/BYOK, and forward-deployed or air-gapped options | | **Best fit** | Teams that want a straightforward Kubernetes PaaS in AWS, GCP, or Azure | Teams that need broader infrastructure, workload, governance, and developer self-service capabilities | [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## FAQs: Northflank vs Porter ### Is Northflank better than Porter? Porter fits teams that want a Kubernetes PaaS in their AWS, GCP, or Azure account. Northflank supports broader deployment options and workloads, including managed databases, GPUs, microVM sandboxes, BYOC, and BYOK. ### How do Northflank and Porter Sandboxes differ? Porter Sandboxes are container-based, AWS-only, and currently in private beta. Northflank Sandboxes use microVM-based isolation and can run on Northflank Cloud and compatible BYOC/BYOK infrastructure. ### Which is better for database support? Northflank supports PostgreSQL, MySQL, MongoDB, Redis, RabbitMQ, and MinIO. Porter currently offers Postgres and Redis on AWS, with GCP and Azure support listed as coming soon. ### Which is better for enterprise teams? Both offer enterprise security controls. Northflank adds broader infrastructure options, granular RBAC, SAML/OIDC SSO, directory sync, audit logs, and forward-deployed or air-gapped deployments for stricter enterprise requirements.

How to deploy coding agents at scale

2026-09-15T15:59:00.000Z

A coding agent can fix a bug, update a dependency, and run tests in one session. When your teams start doing that across many repositories, you also need to control where those sessions run, what they can access, how their changes are reviewed, and what happens to the workspaces they leave behind. Deploying coding agents at scale means making that workflow repeatable across your organisation. This article explains the deployment decisions involved, how to manage parallel work and cost, and where managed coding environments such as Northflank Harnesses fit. ## TL;DR: How to deploy coding agents at scale Deploy coding agents at scale by giving them controlled workspaces, repeatable configuration, scoped access, and a defined route from assigned task to accepted change. - Standardize the agent's tools and runtime while keeping repository access specific to each assignment. - Separate independent tasks and coordinate changes that depend on one another. - Match active work to compute, model-provider limits, test capacity, and reviewer availability. - Preserve the state needed to continue a task and remove resources when the work is finished. - Use managed coding environments when your team needs a repeatable way to provision and operate agent workspaces. If your team needs a managed environment for coding agents, Northflank provides [Harnesses](https://northflank.com/docs/v1/application/ai-agents/harnesses/quickstart): isolated cloud workspaces where agents work with your repositories. They support access through a browser or local terminal and deployment on managed cloud or your own infrastructure. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss coding-agent deployment across your teams. ## What changes when you deploy coding agents at scale? A shared coding-agent deployment needs explicit control over work that a developer might otherwise manage within one local session. Consider a dependency upgrade across several services. Each agent needs the correct repository revision, language runtime, credentials, and tests. Some changes can proceed independently; others depend on a shared library. Reviewers need to understand what changed and whether the services still work together. Starting more agents adds parallel execution, but it also creates more environments and changes to manage. Your deployment should make each assignment attributable to an owner and preserve enough information to reproduce its result. Keep the deployment of the agent separate from the release of its output. Running a coding session successfully does not establish that its changes are ready for production. Both stages need their own permissions, validation, and operational ownership. ## What does a coding agent need beyond access to a model? A coding agent needs a working environment that combines repository files, development tools, execution resources, and access to the services its task requires. The model supplies responses. The agent uses those responses to choose actions such as editing a file or running a test. The environment is where those actions happen. At scale, your team must be able to reproduce and control that environment across many assignments. A practical deployment framework covers these decisions: | Deployment decision | What your team needs to establish | | --- | --- | | Task definition | Repository, starting revision, expected output, and acceptance criteria | | Runtime | Agent and tool versions, dependencies, compute, and storage | | Access | Permitted repositories, credentials, services, and network destinations | | Coordination | Independent workspaces, task ownership, and integration order | | Lifecycle | When to retain, pause, resume, or remove a workspace | | Validation | Checks and review required before a change can be released | The guide to [AI-agent code-execution infrastructure](https://northflank.com/blog/ai-agent-code-execution-infrastructure) explains the broader runtime and security layers. For coding teams, the next decision is how much of the workspace setup and operation they want to manage themselves. ## Where do managed coding environments fit? Managed coding environments provide a repeatable place to run agents while your team defines the work and evaluates the results. This is where Northflank Harnesses fits. Northflank is a platform for running applications and development workloads. Its [Harnesses](https://northflank.com/docs/v1/application/ai-agents/harnesses/quickstart) product brings coding agents into isolated cloud workspaces with repository connections and configurable resources. For a team adopting agents, that creates a concrete deployment unit: a workspace with a purpose, configuration, and lifecycle. You can plan one environment for an ongoing migration and separate environments for unrelated feature work. The benefit is most useful when the same setup needs to serve several people or projects. Your platform team can establish the expected environment, while developers concentrate on the task and its outcome. Workspace management becomes part of the development process rather than something each engineer must recreate around a local session. ## How should you structure a scalable coding-agent deployment? Start with a bounded workload, establish its environment and access requirements, then expand the pattern after validating the results. The following steps are a practical rollout sequence. ### 1. Define tasks your team can evaluate Give each assignment a clear result and stopping point. For example, ask an agent to update one dependency, fix compatibility issues, and produce a patch that passes named tests. Record the repository revision and acceptance criteria before it begins. An open-ended request to improve an application makes it harder to assess progress or decide when to stop. Keep trusted acceptance checks under separate control so the agent cannot satisfy the assignment by weakening its requirements. ### 2. Standardize the working environment Use a maintained baseline for the tools and dependencies a repository needs. Record the agent version, instructions, runtime image, and required configuration. Start with a few workload types your team understands, such as small bug fixes, dependency updates, or test improvements. Adjust resources based on those workloads rather than assigning every session the same large machine. If your team needs repeatable provisioning, Northflank provides a [Harness creation API](https://northflank.com/docs/v1/api/project/harnesses/create-harness) with agent, repository, runtime, resource, and workspace settings. That lets a platform team build a consistent provisioning process while supplying assignment-specific values. ### 3. Limit access to the assignment Give the agent the credentials and connectivity its task requires. Use development credentials and test data. Keep fleet-administration and production-release access outside routine coding workspaces. Treat repository instructions, install scripts, and tool responses as inputs that may be untrusted; a README should not be able to expand the agent's authority. For a practical walkthrough of the execution environment, see [how to run AI coding agents in a secure sandbox](https://northflank.com/blog/how-to-run-ai-coding-agents-in-a-secure-sandbox). When an agent starts an application for inspection, decide who needs to reach it. Northflank provides [Harness networking configuration](https://northflank.com/docs/v1/application/ai-agents/harnesses/configure-and-manage-harnesses#configure-networking) for public or private ports. Exposing a development server should be a deliberate part of the workflow. ### 4. Separate independent work and coordinate shared changes Give unrelated assignments separate workspaces and branches. Separate branches protect work in progress, but their changes still need integration. If two agents modify the same interface, establish which change lands first and rerun tests against the combined result. Define who resolves conflicts instead of leaving multiple agents to repeatedly repair each other's work. Shared workspaces can also be useful for deliberate collaboration. Northflank Harnesses allows multiple team members to work in the same environment in real time. Use that for joint investigation or handoff, with agreement about who is changing what. ### 5. Establish review and completion criteria Make a reviewable change the outcome of the coding session. Require the candidate commit or patch, relevant test results, and a short explanation of the change. Validate it under separately controlled checks and review modifications to tests or deployment configuration. Revalidate after integration changes the candidate. Define completion to include workspace handling. A task can be finished while its environment, credentials, or retained files still need attention. ## How do you control concurrency and cost? Control concurrency according to the capacity of the complete workflow, including models, execution, testing, and review. An agent waiting for a model response may use little CPU while still occupying a workspace. A team can also create changes faster than reviewers can accept them. Measure queue delay, active assignments, task duration, and review backlog before increasing volume. Set limits by team or workload and increase them gradually. When the backlog grows, identify whether the constraint is model access, slow tests, resource sizing, conflicting changes, or reviewer availability. Adding compute helps only when execution capacity is the limiting factor. Track the cost of model use, compute, storage, idle environments, and failed attempts. Assess that alongside review effort and accepted changes. A cheap run that repeatedly needs repair may be less useful than a more expensive run that produces a correct, reviewable result. Managed workspace controls help your team act on those findings. Northflank exposes [Harness CPU and memory metrics and configuration](https://northflank.com/docs/v1/application/ai-agents/harnesses/configure-and-manage-harnesses), so operators can inspect resource use and adjust the environment. Task admissions, model budgets, and acceptance targets remain decisions for your team. ## Should coding-agent workspaces be temporary or persistent? Use temporary workspaces for independent tasks and retained state when an assignment needs to continue across sessions. A quick fix may only need to export its patch and test results. A migration may need to preserve files while a developer reviews progress or another service catches up. Decide what must survive and give that state an owner and retention rule. For continuing work, Northflank supports [pausing and resuming Harnesses](https://northflank.com/docs/v1/application/ai-agents/harnesses/configure-and-manage-harnesses#pause-and-resume-a-harness). Pausing stops processes and terminal sessions while preserving workspace files. Continuing the assignment may therefore require restarting commands. Deleting the Harness permanently removes its associated workspace, so preserve required output first. Avoid leaving retention to individual memory. Include inactive environments in a regular review and distinguish work that is waiting from work that has been abandoned. ## How should agent-generated changes reach production? Agent-generated changes should enter a controlled release process with evidence tied to the actual candidate being deployed. For application changes, reviewing a patch may need to be followed by testing the running stack. Northflank provides [preview environments](https://northflank.com/product/preview-environments) for services, databases, and jobs, and [release workflows](https://northflank.com/docs/v1/application/release/configure-workflows) that connect builds, deployments, checks through jobs, conditions, and approvals. That provides a route from coding workspace to application review and release. Use sanitized data in previews and apply approvals according to the change's impact and delegated authority. Keep a record connecting the assignment, workspace, candidate change, and validation outcome. The guide to [AI-agent execution audit trails](https://northflank.com/blog/ai-agent-code-execution-audit-trail) explains how to join application evidence with infrastructure events. ## When should you choose Northflank Harnesses? Choose [Northflank Harnesses](https://northflank.com/docs/v1/application/ai-agents/harnesses/quickstart) when your team needs managed coding workspaces alongside the infrastructure used to review and deploy applications. If your requirements include isolated cloud development environments, repeatable configuration, collaboration, and application previews and releases, Northflank Harnesses is the default recommendation for this workflow. You can use [Northflank Cloud](https://northflank.com/cloud/northflank) for managed infrastructure or [BYOC](https://northflank.com/features/bring-your-own-cloud) to run workloads in your own cloud account and VPC. With BYOC, Northflank provisions and manages Kubernetes while you own the account. Evaluate external model access separately from workspace location. Start with one representative repository and a task your team can evaluate. Once the environment, review process, and lifecycle work as intended, use that configuration as the baseline for wider adoption. [Get started with Northflank](https://app.northflank.com/signup), follow the [Harnesses quickstart](https://northflank.com/docs/v1/application/ai-agents/harnesses/quickstart), or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your team's deployment requirements. ## Frequently asked questions about deploying coding agents at scale These questions help distinguish workspace choices from the controls around them. ### Does every coding agent need its own workspace? Allocate workspaces around task and trust boundaries. Independent assignments benefit from separate environments; people collaborating on the same authorized task may share one. Avoid mixing unrelated credentials and changes in a writable workspace. ### Does adding more agents increase development throughput? It can, when tasks are independent and testing and review can keep up. Measure accepted changes, rework, and completion time as you increase concurrency. ### Do you need to build an agent platform before adopting coding agents? You can start with managed coding environments and a bounded development workflow. Add custom coordination when your workload requires it, while keeping task ownership, access, validation, and cleanup explicit from the beginning. ## Related articles about coding-agent deployment Continue with these guides to execution and governance. - [How to run AI coding agents in a secure sandbox](https://northflank.com/blog/how-to-run-ai-coding-agents-in-a-secure-sandbox) - [What infrastructure do AI agents need to run code safely?](https://northflank.com/blog/ai-agent-code-execution-infrastructure) - [What should an audit trail for AI-agent code execution contain?](https://northflank.com/blog/ai-agent-code-execution-audit-trail) - [How to give your AI agent a secure computer](https://northflank.com/blog/give-ai-agent-secure-computer) - [How to govern AI-agent code execution in enterprise environments](https://northflank.com/blog/govern-ai-agent-code-execution-enterprise)

How to run autonomous research agents at scale

2026-09-14T16:15:00.000Z

## TL;DR: how to run autonomous research agents at scale - Autonomous research agents combine web search, document retrieval, code execution, and synthesis into an autonomous loop, without requiring human direction at every step. - Running many research agents concurrently introduces infrastructure challenges around session isolation, web access, long-running workloads, credentials, and cost control. - Each research session needs an isolated execution environment so agents can safely browse the web, execute code, and work with files without affecting other sessions or internal infrastructure. - [**Northflank sandboxes**](https://northflank.com/product/sandboxes) provide microVM-isolated execution environments for research agents, with sub-second startup, API-managed lifecycles, and support for running large numbers of concurrent sessions. - [Northflank](https://northflank.com/) can run on [managed cloud infrastructure](https://northflank.com/features/managed-cloud) or [**inside your own cloud with BYOC**](https://northflank.com/product/bring-your-own-cloud), while providing secrets management, persistent storage, and scalable compute for the rest of your research agent stack. > [**Northflank**](https://northflank.com/) provides the infrastructure for running autonomous research agents at scale, from isolated sandboxes for agent execution to secrets management, persistent storage, GPU compute, and BYOC. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > Running one autonomous research agent is straightforward. You give it a goal, it searches the web, reads documents, executes code against the results, and produces a report. The model handles the reasoning. The tools handle the execution. The whole thing runs on your laptop. Running a hundred concurrent research agent sessions for a team of analysts is a different problem. Each session needs its own isolated execution environment. Web access needs to be controlled so agents cannot reach endpoints they should not reach. Sessions may run for minutes or hours. Credentials for internal document stores, APIs, and databases need to be managed centrally and injected per session. The cost of running 100 concurrent sessions needs to be predictable and controllable. None of that comes for free when you scale from one agent to many. ## How autonomous research agents work An autonomous research agent is a system that plans and executes a research workflow without requiring human direction at every step. Given a goal, it decides what information it needs, chooses the tools to use, interprets the results, and produces structured output such as a report, summary, dataset, or answer with citations. The four capabilities that define a research agent: 1. **Web search and retrieval:** The agent queries search engines, fetches web pages, and extracts relevant content. It follows links, reads documents, and filters results based on relevance to the research goal. The agent can perform this process across many sources without requiring a human to review each one. 2. **Document reading and knowledge retrieval:** The agent reads PDFs, research papers, internal documents, and knowledge bases. It extracts relevant passages, identifies key claims, and builds a structured representation of what it has found. The agent can also use vector search or retrieval-augmented generation to access indexed internal knowledge alongside public web content. 3. **Code execution for analysis:** Research agents that work with quantitative data can write and execute code to analyze it, including processing spreadsheets, running statistical calculations, generating charts, or transforming raw data into structured findings. This requires a code execution environment alongside web access and document tools. 4. **Synthesis and report generation:** After gathering and processing information, the agent synthesizes findings across sources and produces structured output. It can cite sources, identify conflicting information, and organize findings into a format the researcher can act on. ## Why running research agents at scale is difficult Scaling research agents from one session to many makes several infrastructure problems significantly harder to manage. - **Session isolation:** When multiple research agents run concurrently, each session needs to be isolated from the others. An agent researching a confidential M&A topic should not be able to access the search results or document cache of another agent working on a different project. Without isolation at the execution layer, concurrent sessions can interfere through shared filesystems, processes, or credentials. - **Web egress control:** Research agents need internet access to do their job. At scale, unrestricted internet access from every agent session creates a larger attack surface. A prompt injection attack embedded in a web page an agent reads could redirect the agent to exfiltrate data or access internal services. Egress policies can restrict which domains or services agent sessions can reach and prevent access to sensitive internal infrastructure. - **Long-running session management:** A research task may take minutes or hours to complete. Long-running workloads need to persist without timing out, running out of storage for downloaded documents, or losing state when a worker restarts. Checkpointing, persistent storage, and lifecycle management allow research tasks to recover from failures without starting over. - **Credential management across sessions:** Research agents that access internal document stores, proprietary databases, or authenticated APIs need credentials. At scale, those credentials should be managed centrally and injected into individual sessions rather than hardcoded into agent configuration. A credential compromise in one session should not expose credentials used by other sessions. - **Cost control:** Running many research sessions concurrently can consume significant compute and model resources. Without controls on session duration, concurrency, and resource allocation, costs can grow quickly. Cost control requires per-session resource limits, automatic teardown when sessions complete, and usage tracking at the workload level. ## How to run research agents on Northflank Northflank sandboxes provide isolated execution environments for research agent sessions. Each sandbox runs in a microVM-backed environment with its own filesystem and network isolation, allowing agents to browse the web, execute code, and work with files without sharing an execution environment with other sessions. A typical workflow is: 1. Create an isolated sandbox for the research task. 2. Inject the credentials the agent needs. 3. Run the research agent inside the sandbox. 4. Persist any results or artifacts that need to survive the session. 5. Remove the sandbox when the task is complete. This lets the research application create isolated environments dynamically as workloads increase, rather than running every agent inside the same application process. For implementation details, see the [Northflank sandboxes documentation](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank). ## How Northflank handles research agent infrastructure Running autonomous research agents at scale requires more than an agent framework. You need infrastructure that can isolate sessions, provide the right compute and storage, control network access, manage credentials, and give teams visibility into what is running. Northflank provides these capabilities as part of a single platform: - **MicroVM isolation:** [Northflank Sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) run in isolated microVMs, giving each research session its own execution environment. This helps prevent concurrent agents from interfering with each other and limits the blast radius of a compromised workload. - **Persistent and ephemeral environments:** Research sessions can use ephemeral environments for short-lived tasks or [persistent volumes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) when they need to retain documents, datasets, intermediate results, and other artifacts. Sandboxes can also scale to zero when they are not running. - **Network controls:** Research agents need internet access to search and retrieve information, but they may also need access to private APIs and internal services. Northflank provides [network controls](https://northflank.com/docs/v1/application/networking) that let teams manage connectivity between workloads and restrict access to sensitive infrastructure. - **Secrets management:** Agents can access API keys, database credentials, and other sensitive configuration without embedding them in source code or container images. [Northflank secrets](https://northflank.com/docs/v1/application/secrets) can be injected into workloads at runtime and managed centrally. - **Enterprise governance:** Teams can manage access with [RBAC and SSO](https://northflank.com/docs/v1/application/teams-and-organisations) and use [audit logs](https://northflank.com/docs/v1/application/teams-and-organisations/audit-logs) to maintain visibility into infrastructure and workload activity. This gives organizations more control as research agents move from individual experiments to production workloads. - **BYOC:** Organizations that need to run research workloads in their own cloud can deploy Northflank into [AWS, GCP, Azure, or other supported cloud](https://northflank.com/docs/v1/application/bring-your-own-cloud). This allows teams to keep workloads and data within their existing cloud infrastructure while using Northflank as the control plane. - **GPU workloads:** Research workflows that require local models, embeddings, or other GPU-intensive processing can run [GPU workloads](https://northflank.com/docs/v1/application/gpu) alongside the agent infrastructure. This makes it possible to keep model inference and research execution within the same platform. - **AI coding environments:** Some research workflows also require an AI coding agent to analyze data, write code, or perform interactive development. [Northflank Harnesses](https://northflank.com/docs/v1/application/ai-agents/harnesses/quickstart) provide dedicated cloud environments for these workflows and can run alongside Sandboxes when both interactive development and isolated agent execution are required. ## Conclusion Running one autonomous research agent is relatively straightforward. Running many concurrent agents reliably introduces a different set of infrastructure challenges: session isolation, web access, credential management, long-running workloads, and cost control. Northflank provides the execution layer for these workloads, with microVM-isolated Sandboxes, persistent storage, secrets management, scalable compute, GPUs, and BYOC for teams that need to run research workloads in their own cloud infrastructure. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ## FAQ: autonomous research agents at scale ### What is an autonomous research agent? An autonomous research agent is an AI system that plans and executes a multi-step research workflow, including searching for information, retrieving documents, analyzing data, and synthesizing findings into structured output. ### What infrastructure does a research agent need to run at scale? Research agents need isolated execution environments, web access, credential management, persistent storage, lifecycle management, and resource controls. At larger scales, concurrency management and observability also become important. ### How do you isolate concurrent research agent sessions? Run each research session in an isolated execution environment. MicroVM-based Sandboxes provide a stronger boundary between concurrent workloads and help prevent one agent session from interfering with another. ### Can research agents run inside my own cloud account? Yes. A BYOC deployment allows research agent infrastructure to run inside your own cloud environment, giving your organization greater control over workload placement, networking, and data residency. ### How do you control the cost of running many research agent sessions? Use resource limits, concurrency controls, session duration limits, and automatic lifecycle management to control how many agents run simultaneously and how long they consume compute resources. ## Related articles - [How to run AI coding agents in a secure sandbox](https://northflank.com/blog/how-to-sandbox-ai-agents) - [How to run browser agents in secure sandboxes](https://northflank.com/blog/how-to-run-browser-agents-in-secure-sandboxes-on-northflank) - [Best enterprise AI sandbox platforms](https://northflank.com/blog/best-enterprise-ai-sandbox-platforms)

How to build secure AI agents for enterprise data

2026-09-14T16:00:00.000Z

## TL;DR: how to build secure AI agents for enterprise data - Enterprise AI data agents touch regulated data, hold privileged access to databases and internal systems, take actions that may be difficult to undo, and operate at scale. Their security requirements are different from general AI agents. - Application-layer policies alone are not sufficient. Infrastructure controls can restrict what an agent can reach, enforce least-privilege access, isolate execution, and provide an audit trail for agent activity. - The six infrastructure controls are: data residency inside your own infrastructure, least-privilege scoped credentials, microVM isolation per session, secrets management, network controls that restrict access to approved services, and audit logging. - [Northflank](https://northflank.com/) provides the infrastructure layer for enterprise data agents, with [managed databases](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), [microVM-isolated Sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank), [secrets management](https://northflank.com/docs/v1/application/secure/security-on-northflank#secret-management), [BYOC](https://northflank.com/product/bring-your-own-cloud), [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [SSO](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication), and [audit logging](https://northflank.com/docs/v1/application/observe/audit-logs) in one platform. - Northflank is SOC 2 Type 2 certified and offers a HIPAA BAA on request. Its forward-deployed control plane supports organizations with additional infrastructure and compliance requirements. [Get started](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). The security risk of an enterprise AI agent is not the model. It is what the model does with its access. An agent connected to your CRM, financial database, HR system, and internal document store has privileged access to data that most employees cannot see. When that agent runs a query, it does so with real credentials against real data, at a speed no human reviewer can keep up with. The blast radius of a misconfigured agent, manipulated prompt, or compromised session is not a wrong autocomplete suggestion. It could be an unauthorized data export, a destructive write operation, or credential exfiltration. The [OWASP Top 10](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) for Agentic Applications 2026 highlights risks including excessive agency, prompt injection, sensitive data exposure, and insufficient logging. But securing these risks requires more than application-level policies. A policy that says “agents should only access the data they need” is difficult to enforce without infrastructure that restricts what the agent can actually reach. This article covers the infrastructure controls that help organizations build and deploy secure AI agents for enterprise data. ## What makes enterprise data agents different from general AI agents An enterprise data agent is not a general-purpose assistant that happens to have database access. It is a system that may operate with privileged access to enterprise data and business systems, which makes the security requirements significantly more demanding. - **Regulated data:** Enterprise agents may handle data subject to HIPAA, GDPR, PCI DSS, or other regulatory requirements. A healthcare agent that reads patient records, a financial services agent that queries transaction data, or an HR agent that accesses employee records operates in a context where unauthorized access or data leakage can have serious regulatory and business consequences. - **Privileged database access:** Enterprise agents may connect to databases using credentials that provide access to sensitive schemas, records, or database operations. Those permissions need to be scoped to what the agent actually requires rather than giving the agent broader access than necessary. - **Actions that cannot always be undone:** Unlike a chatbot that produces text for a human to review, an enterprise data agent can take actions directly. It may update records, submit forms, trigger workflows, or write to databases. A misconfigured or manipulated agent can therefore make changes that are difficult to reverse. - **Scale across users and sessions:** Enterprise agents may run concurrently across teams, users, and workloads. As the number of sessions increases, so does the potential impact of a configuration mistake or security vulnerability. Each session therefore needs appropriate isolation, permissions, and resource controls. ## The six infrastructure controls that secure enterprise data agents Securing an enterprise data agent requires controls around the environment where the agent runs, not just the model or application code. These controls determine what data the agent can access, which systems it can reach, how its credentials are managed, and how its activity is monitored. ### 1. Data residency: keep agent execution inside your own infrastructure Enterprise agents may process sensitive information from databases, internal documents, and business applications. Organizations therefore need to control where the agent runs, where its data is stored, and which parts of the workflow leave their infrastructure. For sensitive workloads, run the agent execution environment inside infrastructure controlled by the organization, such as its own cloud account or on-premises environment. This gives security teams greater control over data residency, networking, storage, and the services the agent can access. ### 2. Least-privilege scoped credentials An enterprise agent should only have access to the data and systems required for its task. A customer support agent may need to read customer records, for example, without having permission to modify financial data or access employee records. Use scoped credentials, database roles, and permissions for different agents, workflows, and environments. Credentials should provide the minimum access required and be centrally managed so they can be rotated or revoked without modifying the agent itself. ### 3. MicroVM isolation per agent session AI agents can execute code, manipulate files, install dependencies, and interact with external services. Running multiple agent sessions in a shared execution environment increases the potential impact of a compromised or misbehaving workload. MicroVM-based isolation provides a stronger boundary between concurrent agent sessions by giving each workload its own isolated execution environment. This helps prevent sessions from interfering with one another and limits the potential blast radius of a compromised agent. ### 4. Centralized secrets management Enterprise agents often need API keys, database credentials, model provider tokens, and credentials for internal services. Storing these credentials in source code, container images, or agent configuration increases the risk of exposure and makes credential rotation more difficult. Store credentials in a centralized secrets manager and provide them to authorized workloads at runtime. This separates credential management from the agent itself and allows security teams to rotate or revoke credentials without rebuilding the application. ### 5. Network controls An enterprise agent needs network access to the services required for its workflow, but unrestricted connectivity increases its potential blast radius. An agent that can reach every internal service or arbitrary external endpoint has more opportunities to access resources it was never intended to reach. Use network policies to restrict connectivity to approved databases, APIs, and external services. Applying these controls at the infrastructure layer provides a boundary around the workload instead of relying entirely on the agent's application code to enforce its own access restrictions. ### 6. Audit logging with identity Enterprise teams need to know which agents are running, who initiated them, which environments they use, and what actions occur during their lifecycle. This becomes increasingly important as agents move from experiments to production workloads. Maintain platform and application-level audit logs that associate activity with the relevant agent, user, or service identity. These records give security teams the visibility needed to investigate incidents, monitor agent activity, and demonstrate that governance controls are being applied. ## How Northflank provides the infrastructure layer for enterprise data agents **What is Northflank?** [Northflank](https://northflank.com/) is a runtime platform for deploying and running enterprise AI workloads, with managed databases, microVM-isolated Sandboxes, secrets management, network controls, enterprise governance, GPUs, and BYOC. [Sign up to get started](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). Northflank provides the infrastructure layer needed to run enterprise AI agents alongside the data, services, and security controls they depend on. - **Data residency with BYOC:** [Northflank BYOC](https://northflank.com/product/bring-your-own-cloud) lets organizations deploy their workloads into their own AWS, GCP, or Azure infrastructure. This gives teams control over where agent workloads, data, and supporting services run while using Northflank to manage the infrastructure. - **Managed databases and storage:** [Northflank managed databases](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank) provide PostgreSQL, MySQL, MongoDB, Redis, MinIO, and RabbitMQ alongside application workloads. Private networking allows agents and supporting services to communicate without requiring publicly exposed database endpoints. - **MicroVM isolation:** [Northflank Sandboxes](https://northflank.com/product/sandboxes) provide isolated environments for running AI agents and other workloads that need stronger execution boundaries. Sandboxes use microVM-backed containers to isolate workloads from one another, making them suitable for agent sessions that execute code or process untrusted inputs. - **Secrets management:** [Secret Groups](https://northflank.com/docs/v1/application/secure/manage-secret-groups) provide centralized management of API keys, database credentials, and other sensitive configuration. Secrets can be made available to authorized workloads at runtime instead of being embedded directly in agent code or container images. - **Network controls:** [Network policies](https://northflank.com/docs/v1/application/network/configure-network-policies) let teams control which services and workloads can communicate with one another. This can be used to restrict an agent's access to the databases, APIs, and other services required for its workflow. - **Enterprise governance:** [RBAC and SSO](https://northflank.com/docs/v1/application/secure/use-role-based-access-control) let organizations control who can deploy and manage workloads across teams, projects, and environments. [Audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) provide visibility into infrastructure activity, helping security and platform teams understand changes and investigate incidents. - **GPU workloads:** [Northflank GPU infrastructure](https://northflank.com/product/gpu-paas) lets agents that require local models, embeddings, classifiers, or other GPU-intensive workloads run on GPUs alongside the rest of the application stack. - **AI coding environments:** [Northflank Harnesses](https://northflank.com/docs/v1/application/ai-agents/harnesses/quickstart) provide dedicated cloud environments for AI coding agents and interactive development workflows. They can be used alongside Sandboxes when an enterprise workflow requires both an AI coding environment and isolated agent execution. Together, these capabilities give enterprise teams a single infrastructure layer for running AI agents, managing the data and services they depend on, and applying security and governance controls across the entire workload. [Get started on Northflank](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your enterprise AI agent infrastructure requirements. ## Conclusion Securing enterprise AI agents is an infrastructure problem as much as a policy problem. Policies can define what agents should be allowed to do, but infrastructure controls are what restrict what they can reach, isolate their execution, and provide visibility into their activity. The six controls: data residency, least-privilege credentials, microVM isolation, secrets management, network controls, and platform-level audit logging provide the foundation for running enterprise data agents with stronger security, governance, and accountability. Northflank provides these capabilities as a managed platform, with BYOC for workloads that need to run in your own cloud infrastructure. ## FAQ: secure AI agents for enterprise data ### What is an enterprise AI data agent? An enterprise AI data agent is an autonomous system that can access an organization's internal data and systems to retrieve information, analyze data, or take actions on behalf of users. ### Why is application-layer security not enough for enterprise AI agents? Application-level policies can define what an agent is allowed to do, but infrastructure controls enforce boundaries around where the agent runs, what it can access, and how its activity is monitored. ### How do you prevent prompt injection attacks in enterprise data agents? Use multiple layers of defense, including least-privilege permissions, isolated execution, restricted network access, secrets management, and application-level prompt injection defenses. Infrastructure controls help limit the impact if an agent is successfully manipulated. ### Can enterprise AI agents run in regulated environments? Yes. Organizations can use controlled execution environments, data residency controls, access management, audit logging, and deployment models such as BYOC to meet the security and compliance requirements of regulated workloads. ### How should database credentials be managed for enterprise AI agents? Database credentials should be stored in a centralized secrets manager and provided to authorized workloads at runtime. Credentials should be scoped to the minimum permissions required and rotated or revoked when necessary. ## Related articles - [How to secure AI agents in the cloud](https://northflank.com/blog/how-to-secure-ai-agents-in-the-cloud) - [How regulated enterprises can run AI-agent sandboxes](https://northflank.com/blog/how-regulated-enterprises-can-run-ai-agent-sandboxes-securely) - [Best enterprise AI sandbox platforms](https://northflank.com/blog/best-enterprise-ai-sandbox-platforms)

How to control access to preview environments across enterprise teams

2026-09-14T15:47:00.000Z

A preview may exist for only a few days, but the application behind its URL may expose an unreleased feature, customer-shaped test data, administrative screens, and access paths to internal services. As preview environments spread across enterprise teams, temporary infrastructure becomes a real identity, network, and data-access boundary. Controlling that boundary means deciding who can create and change previews, who can open them, and what the running workloads can reach. A shared classification model keeps those decisions consistent without forcing every application through the same policy. ## TL;DR: How to control access to preview environments across enterprise teams Control access to preview environments by governing three separate access planes: the platform control plane, the reviewer-facing application, and the dependencies available to the running workload. - Classify each preview by contributor trust, application sensitivity, test-data class, and permitted external side effects. - Use corporate identity, group-based roles, and scoped automation tokens to control who can create, change, inspect, and delete preview infrastructure. - Avoid unauthenticated public exposure by default when previews contain internal applications or sensitive non-production data. - Give preview workloads their own least-privilege secrets, service identities, network routes, and test-system accounts. Do not inject production credentials into pull-request code. - Bind exceptional access and external resources to the pull-request lifecycle, then review platform audit events separately from application access logs. If your platform team needs one access model across many applications, [Northflank Preview Environments](https://northflank.com/product/preview-environments) turn each pull request into a repeatable, isolated environment defined by a [Preview Blueprint](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints). Northflank lets you scope platform actions with [role-based access control](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), protect eligible service ports with organisation SSO, IP, or credential policies, restrict secrets to tagged preview resources, and trace platform changes through audit logs. The result is a common access policy that application teams can consume without owning separate authentication and environment automation. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss preview architecture, identity, networking, compliance, or access requirements. ## Why is preview environment access difficult at enterprise scale? Preview environment access is difficult at enterprise scale because infrastructure permissions, reviewer access, and workload credentials cross teams but require different controls. Treating access as a single public-or-private URL setting secures only one part of the environment. A developer may create a preview without changing its access policy, while a product manager may review it without seeing deployment configuration. Internal engineers, contractors, and external pull requests have different trust levels. A public website and an administrative API also carry different risks. ## What are the three access planes for a preview environment? The three access planes are the control plane for managing preview infrastructure, the reviewer plane for opening the application, and the dependency plane for governing what its workloads can reach. | Access plane | Main question | Typical subjects | Primary controls | | --- | --- | --- | --- | | Control plane | Who can create, change, inspect, or delete the preview? | Developers, platform engineers, CI and security responders | SSO, RBAC, project scope, API tokens and trigger rules | | Reviewer plane | Who can reach the deployed application? | Engineers, QA, product teams, customers and other reviewers | Private access, SSO groups, IP policies and basic authentication | | Dependency plane | What can the running preview reach? | Services, jobs and migration processes | Workload identity, scoped secrets, network policy and data isolation | Authorisation in one plane should not grant access in another. Platform membership does not permit someone to view every application's test data, and reviewers do not need infrastructure permissions. Platform teams define infrastructure controls, security teams define identity and data policy, and application owners classify previews. ## Which factors should determine a preview's access policy? A preview's access policy should be determined by four factors: who supplied the change, what application it affects, which data it uses, and which external actions it can perform. | Preview class | Example | Reviewer access | Workload access | | --- | --- | --- | --- | | Public | Static website change with synthetic content | Public URL may be acceptable | No private services or sensitive secrets | | Internal | Employee application using fixtures | Corporate SSO group | Scoped non-production APIs and data | | Restricted | Customer workflow using masked or customer-shaped data | Named directory groups | Isolated database and narrowly scoped service identities | | High risk | Authentication, billing, infrastructure, or migration change | Named reviewers after required checks | Dedicated test systems, controlled egress, no production credentials | This is a practical taxonomy, not an industry standard. Your enterprise can add residency, regulated data, internet egress, or changes to the preview definition. Store the classification with the repository or preview definition so the environment controller selects the correct rules before a URL exists. ## Who should be allowed to create and manage previews? Platform administrators, preview-template maintainers, application contributors, read-only responders, and CI automation should each receive separate, least-privilege access to previews. A workable role model distinguishes: - Platform administrators who manage organisation identity and policy - Preview-template maintainers who can change topology, networking, and lifecycle rules - Application contributors who can create or inspect previews in their projects - Reviewers and responders who need read-only visibility or logs - Automation identities that can perform only the API actions required by CI If your organisation needs these boundaries across several engineering groups, Northflank [RBAC roles](https://northflank.com/docs/v1/application/secure/use-role-based-access-control) control UI and API operations and can be restricted to selected teams and projects. [SSO and directory sync](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation) can provision organisation members from selected directory groups and automatically assign or remove roles based on group membership. These features require enablement for the organisation. Organisations can also require MFA, set a maximum login-session duration, and clear member sessions. Treat automation as its own identity. Northflank [API tokens inherit an RBAC role](https://northflank.com/docs/v1/application/secure/grant-api-access), can have an expiry, and can be revoked. Give a pull-request workflow only the API permissions and project scope needed to run or update previews, rather than an owner role covering unrelated projects. Trigger policy is part of control-plane access. A trusted internal pull request may create a preview automatically, while an external or high-risk change waits for repository checks. Northflank [Preview Blueprints](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) support pull-request and path rules plus GitHub check-suite triggers, so creation can follow source-control policy. ## Who should be able to open a preview URL? Only the people and systems required to test the change should be able to open a preview URL. Public access should be an explicit choice for low-risk previews, not the default side effect of generating a URL. Use private ports for service-to-service access and automated tests running inside the project. Engineers can reach private deployments and databases through authorised port forwarding or a connected private network. Use enterprise SSO when selected employee groups need browser access. IP allowlists can narrow access to known networks, while basic authentication provides a coarse temporary barrier. Basic authentication lacks the lifecycle and individual attribution of corporate identity. A shared password can outlive a role change and represent several people. Use group-based SSO for internal applications and sensitive test data. Northflank supports [security policies on individual service ports](https://northflank.com/docs/v1/application/network/add-security-policies-for-ports), including organisation SSO groups, IP policies, and basic authentication. [Path-based security policies](https://northflank.com/docs/v1/application/network/create-path-based-security-policies) can apply different access requirements to different paths on the same service port. Northflank [private networking and port forwarding](https://northflank.com/docs/v1/application/network/networking-on-northflank) let authorised users reach services and databases without public exposure. In a multi-service preview, expose the required frontend or gateway and keep databases, workers, and internal APIs private. ## What should preview workloads be allowed to access? Preview workloads should access only the non-production data, services, and external systems required to test the change, using preview-scoped identities. Production access should be denied by default because protecting the URL does not contain code running inside the environment. The dependency-plane policy should cover: - Which secrets the preview receives at build time and runtime - Which services, databases, queues, buckets, and cloud APIs it can reach - Whether outbound internet access is required - Which external test systems it may call - How credentials and external resources are revoked or deleted Pull-request code can read values injected into its process and send them elsewhere. Do not provide production credentials to an untrusted build and assume a hidden variable is safe. Use preview-specific accounts, narrow permissions, and controlled non-production data. If application teams need reusable secret boundaries, Northflank [secret groups](https://northflank.com/docs/v1/application/secure/manage-secret-groups) can separate secret values from ordinary configuration, restrict which roles can see values, and limit inheritance to specific resources or tags. Preview environments receive a default preview tag, allowing preview-only configuration to be scoped to those resources. Private ports, multi-project ingress permissions, and [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies) can limit which internal dependencies are reachable. External systems need their own lifecycle. Tag test tenants, buckets, callbacks, and temporary identities with the preview ID, then delete or revoke them during teardown. ## When should preview access be granted and revoked? Grant preview access only after the change passes its required classification and checks, then revoke it when the pull request closes, merges, expires, or no longer has an owner. At creation, evaluate the change origin and classification before injecting credentials. Mark the preview reviewable only after required checks pass. Give exceptions an owner and expiry. On merge, close, or inactivity, delete the preview and revoke external identities and resources. For lifecycle enforcement, Northflank can update a preview when new commits arrive, set maximum concurrent preview limits, and be configured to [delete previews when a pull request closes or merges, or after a defined period without commits](https://northflank.com/docs/v1/application/release/manage-preview-blueprints). A Preview Blueprint teardown specification can invoke cleanup for resources created in external providers. Your team must still define which external objects were created and how their providers revoke them. ## Which preview access events should your enterprise audit? Your enterprise should audit membership and role changes, automation tokens, preview creation, exposure policies, secret access, exceptions, application requests, and resource deletion. Platform and application events must be reviewed at their respective layers because one log rarely proves both. Review membership, role mappings, privileged changes, API tokens, public exposure, secret permissions, exceptions, stale previews, and orphaned resources. Repeat after identity or shared-template changes. If you need administrative evidence across teams, Northflank [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) record events from users, version control, the UI, API/CLI, preview environment template runs, and the Northflank system. Logs are available at organisation, team, and project scope, with resource-level audit logs for services, jobs, and addons. Platform audit logs are not application request logs. If policy requires evidence of who opened a preview or accessed a particular record, the application, identity proxy, or edge layer must record that event with the permitted identity and retention policy. ## Can Northflank standardise preview access across teams? Yes. Northflank can standardise preview access across teams by combining organisation-level identity controls with reusable Preview Blueprints, project-scoped resources, service access policies, secret restrictions, and lifecycle automation. The organisation, team, and project hierarchy limits administrative scope. A Preview Blueprint defines what an eligible pull request creates, which components are public, which tagged secrets they inherit, and how the environment is removed. Port and path policies control reviewer entry, while audit logs show platform actions. Your enterprise remains responsible for group membership, data classification, dependency permissions, repository trust policy, and exceptions. Northflank makes those decisions repeatable across the preview fleet. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss preview architecture, identity, networking, compliance, or access requirements. ## Frequently asked questions about preview environment access ### Should every preview environment require SSO? Not necessarily. A public static preview with synthetic content may not need identity-aware access. Internal applications, administrative interfaces, customer-shaped data, and sensitive workflows should normally use SSO for named groups or remain private. Derive the requirement from the preview's classification rather than applying one answer to every repository. ### Is basic authentication enough for an internal preview? Only for a low-risk, short-lived preview that does not require individual accountability. Basic authentication provides a simple barrier, but a shared credential is difficult to tie to one person or revoke through normal joiner, mover, and leaver processes. Use corporate SSO when access must follow individual identity or directory-group membership. ### Should external pull requests receive preview environments? Only when the environment can run the change without privileged secrets, sensitive data, or routes to protected systems. An external pull request can first run unprivileged checks, then create a constrained preview after the repository policy's required review or checks. Never expose a production credential merely because the deployment target is temporary. ### Are platform audit logs enough to prove who viewed a preview? No. Platform audit logs show administrative and automation events such as role changes or preview runs. Evidence that a person opened the deployed application normally comes from the SSO proxy, edge access log, or application itself. Retain each log according to the policy it supports. ## Related articles about preview environment security and operations - [Preview environment troubleshooting: Common failures and how to fix them](https://northflank.com/blog/preview-environment-troubleshooting) - [Preview environments for microservices: Architecture and common pitfalls](https://northflank.com/blog/preview-environments-microservices) - [How to auto-create preview environments on every PR](https://northflank.com/blog/how-to-auto-create-preview-environments-on-every-pr) - [Which database strategy should you use for preview environments?](https://northflank.com/blog/which-database-strategy-should-you-use-for-preview-environments) - [How do preview environments scale for AI-generated code?](https://northflank.com/blog/scale-preview-environments-ai-generated-code)

How to monitor and debug AI-agent sandboxes in production

2026-09-14T15:45:00.000Z

An AI-agent sandbox can be running while the agent is stuck in a tool loop, using the wrong credential, sending data to an unexpected destination, or producing an unusable result. Container uptime tells you whether a process is alive, not whether the run is correct, safe, or complete. Production monitoring must connect the task to policy, sandbox, infrastructure, and cleanup events. This article explains the signals, alerts, debugging path, and safe reproduction. ## TL;DR: How to monitor and debug AI-agent sandboxes Monitor and debug AI-agent sandboxes by giving every run a stable identifier, correlating application and infrastructure telemetry, and following failures from admission through execution and cleanup. - Monitor task outcomes, policy behavior, sandbox health, and lifecycle completion separately. A healthy container does not prove that the agent completed its task safely. - Carry an application-owned run ID across the agent, policy engine, tool calls, sandbox, artifacts, and cleanup while retaining each system's native identifiers. - Alert on conditions with a defined response, such as rising startup failures, runaway tool calls, unusual access, resource exhaustion, missing telemetry, and incomplete cleanup. - Debug from the first failed transition in the run timeline instead of starting with unstructured log searches. - Reproduce failures in a restricted non-production sandbox using the same versioned inputs and sanitized data, not live production credentials. If your team runs generated or untrusted code, Northflank provides isolated [Sandboxes](https://northflank.com/product/sandboxes) alongside logs, metrics, health checks, alerts, log export, and audit events. Northflank is an AI-agent sandbox and workload platform for running untrusted code in isolated environments on [Northflank Cloud](https://northflank.com/cloud/northflank), in your own cloud account and VPC through [self-serve BYOC](https://northflank.com/features/bring-your-own-cloud), or on a compatible existing Kubernetes cluster, including eligible on-premises infrastructure, through [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok). Your application still needs to emit agent telemetry and correlate it with Northflank identifiers. [Get started with Northflank](https://app.northflank.com/signup) self-serve to evaluate sandbox observability, isolation, networking, and deployment workflows, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your architecture, security, compliance, data residency, or scale requirements. ## What does production AI-agent sandbox monitoring need to tell you? Production monitoring should answer four questions: is the infrastructure healthy, did the agent complete the task, did it stay within policy, and did temporary resources end as intended? Treat the four outcomes as independent states: - **Infrastructure health:** Was the sandbox admitted, created, made ready, and given enough compute, memory, storage, and network capacity? - **Task correctness:** Did the agent achieve the requested result, pass validation, and produce the expected artifact or business effect? - **Policy compliance:** Were tools, credentials, data, destinations, approvals, and resource use within the authority granted to this run? - **Lifecycle completion:** Were child processes stopped, credentials revoked, artifacts exported, state handled, and the environment deleted or paused according to policy? If your team needs the execution platform to distinguish startup from availability, Northflank provides [startup, readiness, and liveness health checks](https://northflank.com/docs/v1/application/observe/configure-health-checks) for deployed workloads. Startup, readiness, and liveness probes test whether startup has completed, whether the container should receive traffic, and whether it should be replaced. ## Which telemetry should an AI-agent sandbox emit? An agent run needs four evidence layers. | Layer | Useful signals | Questions it answers | | --- | --- | --- | | Agent and task | Agent, model, prompt and configuration versions; permitted input and output references; task status; validation result; token use; latency | What was the agent trying to do, and did it succeed? | | Policy and tools | Policy version and decision; approval; tool request and result; credential ID and scope; denied action; retry | Why was an action allowed, denied, or repeated? | | Sandbox runtime | Environment and image IDs; readiness; command start and exit; stdout and stderr where permitted; CPU, memory, storage, network, timeout and termination | What ran, where did it fail, and which limit applied? | | Platform and infrastructure | Admission and scheduling; resource changes; container lifecycle; health checks; cluster capacity; audit events; cleanup confirmation | Did the execution plane provision, operate, and remove the environment correctly? | Create an application-owned identifier before admission and add it to telemetry, sandbox metadata, artifacts, and cleanup. `run_id` is one possible name. Preserve native trace, tool-call, container, credential, and platform-event IDs alongside it. Propagate trace context across services to correlate traces and logs. Sanitize context received from untrusted callers, and do not add secrets or sensitive personal data to propagated fields because they may reach downstream or external services. ## Which metrics and alerts are useful for AI-agent sandboxes in production? Useful metrics expose a failed boundary or trigger a response. Set thresholds from your workload baseline, risk, and service objective. ### 1. Admission and startup Measure requested, denied, queued, and started runs, queue age, creation latency, readiness failures, scheduling failures, and capacity by execution class or tenant. Alert when startup success falls, queue age keeps rising, or one tenant consumes a disproportionate share of capacity. If your platform service needs to automate this lifecycle, Northflank provides [API-controlled sandbox creation and execution](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank). Your application can create an isolated environment, poll its deployment status, execute commands, and collect stdout, stderr, and exit results against its own run record. ### 2. Execution and task outcome Measure duration, tool latency, exit status, retries, timeouts, validation failures, and outcomes. Segment by agent, model, tool, image, policy, and release version. Do not make command success the task success metric. Validate the artifact or effect the user requested, such as tests, policy checks, and an exported patch. ### 3. Resource use and cost Track CPU, memory, storage, output, network traffic, model tokens, duration, concurrency, and cost per run and successful outcome. Watch distributions and high percentiles, then alert on sustained saturation, repeated evictions, abnormal output, or cost without task progress. Apply limits and circuit breakers for abnormal cost, latency, retries, and tool-call behavior. If your operations team needs to test whether infrastructure pressure caused a failure, Northflank provides [container metrics](https://northflank.com/docs/v1/application/observe/view-metrics) for CPU and memory usage, persistent-volume capacity, public and private network requests and bandwidth, and log lines generated per second. These network metrics show traffic levels rather than destination-level activity. Combine the platform signals with application-level token, tool, and outcome metrics rather than treating them as the complete cost of an agent run. ### 4. Security and policy behavior Monitor tool denials, approval bypass attempts, elevated access, unexpected destinations, sensitive-data access, policy changes, and high-risk action frequency. Compare activity with the run's purpose rather than treating every uncommon action as malicious. Monitor decisions, tools, outcomes, approvals, policy versions, anomalies, token use, and cost in a structured format. Alerts should be able to invoke containment, not only notify a dashboard. If agent sandboxes need enforceable network and credential boundaries, Northflank provides [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies) for restricting ingress and egress on BYOC clusters. The platform also provides [API tokens whose permissions derive from an associated RBAC role](https://northflank.com/docs/v1/application/secure/grant-api-access). Tokens can be configured with an expiry and revoked independently, while Enterprise plans provide token-specific audit-log feeds. ### 5. Lifecycle and telemetry integrity Measure expired environments, cleanup latency, failed deletion, retained volumes, credential revocation, orphans, and telemetry delivery. Alert on missing run endings, unconfirmed deletion, surviving credentials, and log-stream gaps. Silence is not proof of inactivity. If evidence must remain available after an ephemeral sandbox is deleted, Northflank provides [log sinks](https://northflank.com/docs/v1/application/observe/configure-log-sinks) that forward runtime logs and can optionally include CDN and network-mesh logs. These logs do not replace destination-aware network or DNS telemetry when an investigation requires it. Monitor delivery to the configured observability or storage destination so a failed export becomes an operational signal of its own. ## How should you debug a failed AI-agent sandbox run? Debug a failed run by finding its first incorrect transition, then moving outward only when the evidence requires it. ### 1. Freeze the run identity and current state Start with the run, trace, tool-call, sandbox and container IDs, plus the image digest, agent and policy versions, timestamps, and lifecycle state. Pause automated deletion only if incident policy permits it, without leaving credentials or network access active. ### 2. Classify the observed failure Classify the symptom as admission, startup, execution, tool access, task validation, policy, persistence, cleanup, or telemetry loss. This gives the investigation an owner and hypothesis. ### 3. Reconstruct the timeline Order the request, policy decision, creation, readiness, tool activity, resource changes, artifact export, termination, and cleanup. Separate requested actions from executed actions and effects. If your team needs to reconstruct runtime and infrastructure events together, Northflank provides [live and historical logs](https://northflank.com/docs/v1/application/observe/view-logs) for running and terminated containers and job runs. Its [platform audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) show infrastructure and configuration events. Join both to the application trace. ### 4. Compare the failing run with a known-good run Diff the code, image, dependencies, agent configuration, model, tools, policy, credential scope, resources, network rules, data references, and feature flags. ### 5. Test the infrastructure hypothesis Check scheduling, readiness, health probes, container state, exit code, CPU, memory, storage, traffic, and cluster capacity. If your team needs these signals in one operational view, Northflank provides [container monitoring](https://northflank.com/docs/v1/application/observe/monitor-containers) that combines container status, health results, logs, and resource and network metrics. A misconfigured startup or liveness probe can replace an otherwise healthy container, while a failing readiness probe removes it from the load balancer. ### 6. Reproduce with reduced authority Create a new sandbox from the same immutable versions, but use sanitized inputs, test credentials, restricted networking, and no production write access. Change one variable at a time and record where the reproduction diverges from the original. ### 7. Contain, confirm, and close Depending on impact, terminate the run, block admissions, revoke credentials, disable a tool or policy, restrict networking, and quarantine state or artifacts. Confirm each action, add a regression test, and update the runbook. Assign incident-response ownership, rehearse the process, and use retrospectives to improve it. ## How do you distinguish common AI-agent sandbox failure modes? A timeout can originate in the queue, sandbox, model, tool, or cleanup path. Use the earliest abnormal signal to narrow the layer. | Symptom | Likely layer | Evidence to inspect | Next action | | --- | --- | --- | --- | | Run stays queued | Admission or capacity | Queue age, denial, scheduler and cluster state | Check quotas, policy dependency and capacity | | Sandbox never becomes ready | Image, startup or infrastructure | Startup logs, probes and scheduling events | Compare the image and correct probes or capacity | | Container restarts or is evicted | Runtime resources | Exit reason, memory, storage, CPU and logs | Fix the workload or justify a new limit | | Run repeats actions | Agent or tool loop | Tool sequence, retries, progress and tokens | Stop it and tighten recursion or progress limits | | Tool call is denied | Policy, identity or arguments | Policy decision, credential scope, approval and sanitized arguments | Correct the request or policy, not the sandbox resources | | Data leaves unexpectedly | Network or tool policy | Destination-aware network and tool telemetry | Block the path, revoke access and investigate | | Expected artifact is missing | Task, filesystem or export | Validation, path, storage and export event | Reproduce the write and export transition | | Access survives deletion | Cleanup | Revocation, child work, volume and deletion status | Contain resources and repair reconciliation | | Dashboard has no run ending | Telemetry pipeline | Export errors, schema failures, sink health and dropped events | Treat the visibility gap as an operational incident | ## How should you reproduce AI-agent sandbox failures safely? Reproduce a production failure with the same versioned environment and less authority. Preserve the image, code, dependencies, agent configuration, model, tools, policy, resources, and sanitized inputs needed to test the hypothesis. Use a separate environment with test credentials, restricted egress, approved data, and cost and time limits. Prefer a read-only interface, recorded response, or controlled stub for production dependencies. If collected evidence cannot explain the failure, Northflank provides [shell access to applicable running containers](https://northflank.com/docs/v1/application/observe/monitor-containers) for last-mile diagnosis. Interactive access changes state, so use telemetry first and record who opened the shell, when, why, and what changed. ## How does Northflank support production AI-agent sandbox observability? Northflank supplies execution and infrastructure observability while your application emits agent, policy, tool, and task telemetry. Northflank is an AI-agent sandbox and workload platform for running untrusted code in isolated environments on [Northflank Cloud](https://northflank.com/cloud/northflank), in your own cloud account and VPC through [self-serve BYOC](https://northflank.com/features/bring-your-own-cloud), or on a compatible existing Kubernetes cluster, including eligible on-premises infrastructure, through [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok). - [Northflank Sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) provide API-controlled isolated environments and command execution with stdout, stderr, and exit results. - [Logs and container monitoring](https://northflank.com/docs/v1/application/observe/observability-on-northflank) cover builds, deployments, jobs, addons, container state, resource use, network traffic, and health checks. - [Infrastructure alerts](https://northflank.com/docs/v1/application/observe/set-infrastructure-alerts) cover crashes, eviction, CPU and memory pressure, volume capacity, and cluster issues, with notification integrations for routing events. - [Log sinks](https://northflank.com/docs/v1/application/observe/configure-log-sinks) forward runtime logs and can optionally include CDN and network-mesh logs for configured observability or storage destinations. - [Audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) show platform events, origin, triggering identity, affected resources, parent events, and configuration changes. Use [Northflank Cloud](https://northflank.com/features/managed-cloud) for managed infrastructure. Use self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud) to run workloads and storage in your own cloud account and VPC while Northflank manages Kubernetes. [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements) connects a compatible existing Kubernetes cluster your team operates. If your enterprise needs isolated code execution, Kubernetes orchestration, infrastructure observability, GPU workloads, and deployment in your own cloud account and VPC, Northflank is our default recommendation for running AI-agent sandboxes. Startups and individual engineers can use the same platform through its self-serve developer experience. [Get started with Northflank](https://app.northflank.com/signup) self-serve to test the monitoring architecture with your own sandbox workload or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your architecture, security, compliance, data residency, or scale requirements. ## Frequently asked questions about monitoring AI-agent sandboxes These answers clarify common production boundaries. ### Are logs enough to debug an AI-agent sandbox? No. Debugging also needs traces, metrics, versions, policy decisions, tool results, lifecycle state, and task validation. Audit events or network telemetry may be needed for infrastructure and security questions. ### Should you record prompts and model outputs? Only where policy permits. Prompts, outputs, arguments, and files can contain code, credentials, personal data, or hostile content. Prefer identifiers and protected references; retain redacted content only for a defined need. ### What should trigger an automatic sandbox shutdown? It depends on impact. Candidates include expiry, sustained resource or cost limits, runaway recursion, prohibited destinations, invalid approval, credential misuse, or loss of a required control. Decide whether each condition denies an action, terminates a run, or blocks an execution class. ### How do you monitor ephemeral sandboxes after deletion? Export telemetry and artifacts outside the sandbox before deletion. Keep confirmation events for credential revocation, state handling, and resource removal. ## Related articles about AI-agent sandboxes Continue with these related implementation guides. - [What should an audit trail for AI-agent code execution contain?](https://northflank.com/blog/ai-agent-code-execution-audit-trail) covers durable execution evidence. - [What infrastructure do AI agents need to run code safely?](https://northflank.com/blog/ai-agent-code-execution-infrastructure) maps the control and execution layers. - [How to govern AI-agent code execution in enterprise environments](https://northflank.com/blog/govern-ai-agent-code-execution-enterprise) connects execution policy to identity, data, networking, evidence, and containment. - [How to scale AI-agent sandboxes for high-concurrency workloads](https://northflank.com/blog/scale-ai-agent-sandboxes-high-concurrency) covers admission control, warm capacity, quotas, and lifecycle automation. - [How to deploy an AI agent from sandbox to production](https://northflank.com/blog/how-to-deploy-ai-agent-from-sandbox-to-production) explains the controlled path from isolated development to a production workload.

How to build and run an AI data analysis agent

2026-09-11T16:30:00.000Z

## TL;DR: how to build and run an AI data analysis agent - An AI data analysis agent combines a language model with tools for querying databases, executing Python, accessing files, and working with the data sources required for analysis. - The agent can autonomously choose which tools to use, execute them in sequence, interpret the results, and produce an answer, visualization, or report. - Production data analysis agents need sandboxed execution because they run AI-generated SQL and Python against real data. A misconfigured agent or prompt injection can otherwise lead to unintended queries, data access, or resource usage. - [Northflank](https://northflank.com/) provides the infrastructure for running these agents, with GPU workloads for hosting models, services for the agent, isolated sandboxes for generated code, managed databases and storage for data, and networking, secrets, and enterprise governance controls. - Run the entire stack on Northflank's [managed cloud](https://northflank.com/features/managed-cloud) or [in your own cloud through BYOC](https://northflank.com/features/bring-your-own-cloud). > Build and run your AI data analysis agent on Northflank. [Get started with Northflank (self-serve)](https://app.northflank.com/signup), or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to explore the right setup for your workloads and infrastructure. > Data analysis agents do not wait to be asked a question. They connect to your databases, run queries, execute Python against the results, interpret what they find, and produce reports autonomously. Point one at your PostgreSQL database and ask it to identify revenue trends by region for the last quarter. It writes the SQL, runs it, processes the output, and returns a structured analysis. No dashboard. No SQL engineer. No waiting. Building an agent against a sample dataset is straightforward. Running one in production against real customer data, with real database credentials and autonomous code execution, is a different problem. The agent needs sandboxed execution so a misconfigured query or manipulated prompt cannot access more than it should. Database credentials need to be managed centrally and injected at runtime, while teams with data residency or network requirements may need to run the agent inside their own cloud infrastructure. This article covers both sides: building the agent and running it safely in production. ## What an AI data analysis agent actually does An AI data analysis agent is more than a chatbot with database access. It can plan a data analysis, choose the tools it needs, execute queries or code, interpret the results, and produce a final answer without requiring a human to handle each step. The core capabilities are: 1. **Natural language to SQL or Python:** The agent interprets a question in plain English and translates it into the queries or code needed to answer it. For example, “Which product categories drove the most revenue growth last quarter?” might require the agent to identify the relevant tables, filter the correct dates, calculate growth, and aggregate the results. 2. **Tool calling and execution:** The agent does not just generate SQL or Python. It calls tools that execute them. A SQL tool can query a database, a Python tool can perform data manipulation or statistical analysis, and a file tool can read datasets or write reports. The agent decides which tools to use based on the task and the results it receives. 3. **Result interpretation and synthesis:** The agent inspects the output from its tools, identifies relevant findings, and determines whether additional analysis is needed. It can then combine the results into an explanation rather than simply returning raw query output. 4. **Report generation:** The final output can be a written analysis, table, chart, or report with the findings and recommendations relevant to the original question. ## Why production data analysis agents need sandboxed execution Running an AI data analysis agent against real production data introduces risks that do not exist in a local prototype. - **AI-generated code runs with real permissions:** The agent writes and executes SQL and Python autonomously, and that code has access to whatever the underlying connections permit. A destructive query generated because of a hallucination, bug, or prompt injection can execute with the same permissions as a legitimate query. Sandboxed execution provides a separate boundary for generated code and helps contain its effects. - **Prompt injection via data:** A data analysis agent can process user-generated or otherwise untrusted data. A malicious value in a `user_comments` column, for example, could contain instructions designed to influence the agent, such as accessing unrelated data or sending information to an external endpoint. The execution environment should constrain what the agent can access even when the data it reads is adversarial. - **Database credentials are high-value targets:** An agent that connects to a production database may have access to sensitive data and operations. Database credentials should therefore be managed centrally, scoped to the task, and injected at runtime rather than hard-coded into the application or execution image. - **Multi-tenant isolation:** When multiple users or teams run data analysis agents, each execution environment should be isolated from the others. One agent should not be able to access another user's files, query results, credentials, or running processes. - **Data residency:** Some organizations need data processing to remain within a specific cloud account, region, or network boundary because of regulatory or contractual requirements. In those cases, the agent and its execution environment may need to run inside the organization's own infrastructure rather than on shared external infrastructure. ## How to build and sandbox an AI data analysis agent on Northflank The architecture of an AI data analysis agent has three layers: the model that reasons and plans, the tools it calls to interact with data, and the execution environment where those tool calls run. ![image.png](https://assets.northflank.com/image_f041bc24b3.png) **The model layer** handles reasoning and planning. Given an input, it decides which tools to call, what arguments to pass, and how to interpret the results. Tool calling APIs from model providers let the model return structured tool calls that the agent runtime executes. You can also run models on [Northflank's GPU infrastructure](https://northflank.com/product/gpu-paas) when you need to host your own models. **The tool layer** defines what the agent can do. A SQL query tool can execute a query and return rows, a Python execution tool can run analysis code, and a file tool can read datasets or write output files. Each tool connects to the resources required by the analysis and returns the results to the agent. **The execution layer** is where those tool calls actually run. For a production data analysis agent, this means: - SQL queries run against a database using credentials scoped to the agent's workload rather than hardcoded credentials. - Python and other generated code run inside an isolated sandbox so the execution environment is separated from the agent service and underlying host. - File operations are restricted to the workspace and storage the agent is explicitly given, with ephemeral or persistent storage depending on the workflow. On Northflank, the execution layer can use [microVM-isolated Sandboxes](https://northflank.com/product/sandboxes) for Python and other generated code, alongside [managed databases](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank) for structured data. Database credentials can be stored in [secret groups](https://northflank.com/docs/v1/application/secure/manage-secret-groups) and provided to workloads at runtime. The agent itself can run as a Northflank service, with sandbox environments created programmatically when additional code execution is required. For the full SDK reference on creating and managing sandbox environments, see the [Northflank Sandboxes documentation](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank). Build and run your AI data analysis agent on Northflank. [Get started with Northflank (self-serve)](https://app.northflank.com/signup), or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to explore the right setup for your workloads and infrastructure. ## How Northflank handles AI data analysis infrastructure Running a data analysis agent in production means operating more than the model. Someone has to provide the database the agent queries, isolate generated code execution, manage credentials, store analysis outputs, and support the infrastructure as workloads grow. Northflank provides the infrastructure and execution layer around the agent, from the environment where you build and run the agent to the isolated environments where generated code executes. - [**MicroVM sandbox isolation**](https://northflank.com/product/sandboxes): Run AI-generated Python and other untrusted code inside microVM-backed Sandboxes with VM-level isolation. Sandboxes boot in under 1 second and can be created and managed programmatically. - [**Harnesses**](https://northflank.com/docs/v1/application/ai-agents/harnesses/quickstart): Use cloud coding environments to build, test, and run AI-powered workflows with dedicated compute, storage, networking, and runtime configuration. Harnesses can be used alongside Sandboxes when your data analysis workflow also includes an AI coding agent or interactive development environment. - [**Managed databases and storage**](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank): Run PostgreSQL, MySQL, MongoDB, Redis, and MinIO alongside your agent workloads. Database connection details can be provided to services and jobs through runtime variables or secret groups. - [**Secrets management**](https://northflank.com/docs/v1/application/secure/manage-secret-groups): Store database credentials, API keys, and other sensitive values in secret groups and provide them to workloads at runtime. Secrets can be restricted to specific services or jobs. - [**Managed cloud**](https://northflank.com/features/managed-cloud) or [**BYOC**](https://northflank.com/product/bring-your-own-cloud): Run the agent, sandbox execution, and supporting infrastructure on Northflank's managed cloud or in your own cloud environment through BYOC. - [**Network controls**](https://northflank.com/docs/v1/application/network/configure-network-policies): Control how agent workloads communicate with databases, APIs, and other services using Northflank's networking and policy controls. - [**Enterprise governance**](https://northflank.com/enterprise): Control who can deploy and manage agent workloads with role-based access control and enterprise SSO through SAML and OIDC. Audit logs provide visibility into infrastructure and configuration changes for investigating unexpected behavior. - [**Services, jobs, and storage**](https://northflank.com/docs): Run the agent API as a service, move long-running analysis into jobs, and use persistent storage when datasets or generated artifacts need to survive beyond a single execution. - [**GPU workloads**](https://northflank.com/product/gpu-paas): Run GPU-backed workloads when the analysis workflow also requires local model inference, vision models, or other GPU-accelerated processing. The point is not to replace the agent framework or dictate which model you use. You build the reasoning and tool-calling layer while Northflank provides the environment those tools run against, from sandboxed code execution and databases to storage, networking, and infrastructure. Build the agent logic. Let Northflank handle the infrastructure it runs on. ## Conclusion Building an AI data analysis agent is only part of the problem. Once the agent works with real data and executes SQL or Python autonomously, production introduces new challenges around sandboxed execution, credential management, data access, and infrastructure. Northflank provides the infrastructure layer those agents need: managed databases for data, microVM-isolated Sandboxes for generated code execution, secrets management for credentials, networking and governance controls, and BYOC for teams that need to run workloads in their own cloud infrastructure. ## FAQ: how to build and run an AI data analysis agent ### What is an AI data analysis agent? An AI data analysis agent connects to data sources, generates and executes queries or code, interprets the results, and produces structured analysis without requiring a human to handle each step. Unlike a BI dashboard with predefined metrics or a chatbot that answers a single question, an agent can plan and execute a multi-step analysis using tools for database access, code execution, and file management. ### What tools does a data analysis agent need? At minimum, a data analysis agent needs a SQL query tool and a Python execution tool. Production agents may also need file tools for reading datasets and generating reports, as well as API tools for pulling data from external sources. The model chooses which tools to call as it works through the analysis. ### Why does a data analysis agent need a sandbox? Data analysis agents execute AI-generated SQL and Python against real data and infrastructure. A hallucinated query, misconfiguration, or prompt injection can cause unintended data access, expensive queries, or destructive actions. A sandbox isolates generated code from the host and other workloads while limiting the resources and services it can access. ### Can a data analysis agent run inside my own cloud account? Yes. Northflank BYOC lets you run the agent and its supporting workloads in your own cloud infrastructure, including AWS, GCP, Azure, Oracle, and CoreWeave. This is useful when data or workloads need to remain within your organization's cloud environment and network. ### How do you secure database credentials for a data analysis agent? Store database credentials in a secrets manager and provide them to the agent at runtime rather than hardcoding them in source code or configuration files. On Northflank, secret groups can provide credentials to the workloads that need them while keeping them separate from the generated code execution environment. ## Related articles - [Best enterprise AI sandbox platforms](https://northflank.com/blog/best-enterprise-ai-sandbox-platforms) - [How to secure AI agents in the cloud](https://northflank.com/blog/how-to-secure-ai-agents-in-the-cloud) - [Top managed database services](https://northflank.com/blog/top-managed-database-services)

Dokploy vs Render: which deployment platform should you choose?

2026-09-11T16:11:00.000Z

Dokploy and Render simplify deployment in different ways. Dokploy gives you an open-source control plane for selected servers, while Render runs applications and managed datastores on Render infrastructure. Your decision starts with how much of the platform your team wants to own, then extends to deployment workflows, previews, databases, scaling, team controls, and total cost. ## TL;DR: Dokploy vs Render Dokploy gives you more direct control over the servers beneath your applications, while Render provides a managed application platform with compute included as a separate usage charge. - **Dokploy** is designed for teams that want an open-source, Docker-based deployment control plane on selected servers. It supports applications, Compose projects, database containers, scheduled jobs, previews, remote servers, and Docker Swarm clusters. - **Render** is designed for teams that want to deploy web services, private services, workers, cron jobs, Workflows, Postgres, and Key Value without preparing or maintaining the underlying hosts. - **The operating boundary drives the decision.** With Dokploy, your team supplies and operates the workload servers. Render operates both its platform and the infrastructure used by Render services. - **Northflank is the recommended option** when you need managed infrastructure and a path to your own cloud account under one platform. It runs services, jobs, managed databases, full-stack previews, and CPU or GPU workloads on Northflank Cloud or through self-serve BYOC. If you want the convenience of a managed application platform without giving up infrastructure choice, [Northflank](https://northflank.com/) provides managed Kubernetes and application delivery in one platform. Use [Northflank Cloud](https://northflank.com/cloud/northflank) or [self-serve BYOC](https://northflank.com/features/bring-your-own-cloud), which provisions and manages Kubernetes in your cloud account and VPC. The same workflow covers services, jobs, managed data, previews, autoscaling, observability, secrets, and GPUs. [Get started with Northflank](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) for production, migration, security, or compliance requirements. ## Dokploy vs Render comparison table The three platforms overlap on Git-based application delivery, but differ in infrastructure ownership, workload scope, and how production operations are packaged. | Platform | Dokploy | Render | Northflank | | --- | --- | --- | --- | | Best for | Running Docker applications on servers your team selects and operates | Running conventional web applications and managed datastores on provider infrastructure | Running production services, jobs, databases, previews, and CPU or GPU workloads on managed or customer-cloud infrastructure | | Operating model | Self-hosted or Dokploy-managed control plane with workloads on your servers | Managed application platform and Render infrastructure | Managed application platform and Kubernetes orchestration on Northflank Cloud or in your cloud account | | Deployment sources | GitHub, Git, Docker images, Dockerfiles, buildpacks, Nixpacks, and Docker Compose | Git repositories, Docker images, native runtimes, Blueprints, dashboard, CLI, and API | Git repositories, Dockerfiles, buildpacks, registries, templates, dashboard, API, CLI, and GitOps | | Workloads | Applications, Compose and Stack projects, database containers, and scheduled jobs | Web and private services, static sites, workers, cron jobs, Workflows, Postgres, and Key Value | Services, jobs, managed databases, caches, queues, storage, and CPU or GPU workloads | | Preview environments | GitHub pull-request previews for individual applications, with cleanup after closing or merging | Standalone service previews, plus multi-resource Blueprint previews on Pro or higher, with automatic PR cleanup | Full-stack previews with services, jobs, databases, volumes, networking, and automatic cleanup | | Scaling | Vertical server scaling, remote-server placement, or Swarm replicas | Vertical scaling, manual horizontal scaling, or CPU and memory autoscaling on Pro or higher | Horizontal autoscaling, configurable vertical scaling, and BYOC node-pool controls | | Infrastructure choice | Compatible customer-supplied Linux servers | Render infrastructure | Northflank Cloud, self-serve BYOC, or eligible Kubernetes infrastructure through BYOK | | Team controls | Standard roles; Enterprise adds custom roles, SSO, SCIM, and audit logs | Plan-based roles and audit logs; Scale and Enterprise add SAML SSO and SCIM | RBAC and secrets; Enterprise adds SSO, directory sync, audit logs, policy controls, HA/DR, and custom SLAs | | Pricing model | Free self-hosting or annual Cloud plans from $4.50 per connected server per month, plus infrastructure | Workspace subscription plus compute, storage, bandwidth, and other usage | Free Developer Sandbox, per-second pay-as-you-go without seat fees, BYOC platform pricing, or custom Enterprise pricing | ## What are the main differences between Dokploy and Render? The largest differences are infrastructure ownership, application structure, and production operations. ### Infrastructure and deployment architecture Dokploy can place its UI, builds, and applications on one Linux server, connect independent servers over SSH, or join servers to a Docker Swarm cluster. Your team selects the provider and remains responsible for capacity and server operations. Dokploy Cloud hosts and updates the control plane, then connects to your servers to install Docker, Traefik, and its monitoring agent. Your servers still run the workloads. Render packages the control plane and workload infrastructure together. You create a service, choose its compute plan, connect a repository or image, and let Render build and run containerized instances. Render also manages routing, TLS, private networking, service discovery, and the host layer. ### Application and release workflows Dokploy applications can build from GitHub or generic Git, pull a Docker image, or use Dockerfiles, buildpacks, or Nixpacks. Compose and Stack cover multi-container definitions, while Traefik handles domains and certificates. Render supports linked Git repositories, Docker images, native runtimes, automatic deploys, and zero-downtime workflows where the service configuration permits them. Blueprints define services, datastores, and environment groups in a version-controlled `render.yaml` file. Dokploy creates previews for GitHub-connected applications, with a configurable maximum that defaults to three. Render provides standalone previews for web services and static sites, including pull-request previews for Git-backed services and image previews for container-registry deployments. Render also provides multi-resource preview environments on Pro or higher. These create the services, datastores, and environment groups described in a Blueprint and are billed like other resources. Existing datastore data is not copied. Git-backed service previews, Dokploy pull-request previews, and Render preview environments clean up automatically when the pull request closes or merges. ### Databases and persistent data Dokploy provides PostgreSQL, MySQL, MariaDB, MongoDB, and Redis as containers on your servers. It schedules backups to S3-compatible storage, while the operator remains responsible for database placement, patching, retention, backup security, and restore testing. Render Postgres and Render Key Value are managed datastores. Paid Postgres includes continuous backups for point-in-time recovery, while eligible database compute configurations can add read replicas and high availability. Render services can also attach persistent disks when an application needs filesystem state. An attached Render disk changes deployment and scaling behavior. A disk belongs to one service instance, so that service cannot scale horizontally. It also prevents zero-downtime deployments because Render stops the existing instance before starting its replacement. Stateful applications therefore need a separate datastore when multiple instances or uninterrupted deployments are required. ### Scaling and operations Dokploy's default single-server path scales vertically by adding resources at the server provider. Independent remote servers separate placement, while Docker Swarm supports application replicas across nodes. A Swarm deployment still requires decisions about registry access, node capacity, networking, storage, monitoring, and recovery. Render scales vertically by changing a service's compute plan. Web services, private services, and background workers can also scale manually to multiple instances. Pro and higher plans add autoscaling between configured minimum and maximum counts based on CPU or memory utilization. Each running instance uses its selected compute rate. Dokploy gives your team direct host access, plus responsibility for patching, firewall rules, Docker operations, storage, monitoring, and recovery. Render absorbs those host-level tasks, while applications run within its service types, plans, regions, and resource model. ### Team and enterprise controls Dokploy's open-source edition includes Owner, Admin, and Member roles. The Dokploy Cloud Startup plan adds its Admin and Developer role model plus 2FA. Dokploy's Enterprise editions add custom roles, SSO through OIDC or SAML, SCIM provisioning, audit logs, application authentication, and priority support. Enterprise can be self-hosted with a paid licence or delivered through Dokploy Cloud. Render Hobby supports one workspace member. Pro supports unlimited members, workspace audit logs, network-isolated environments, autoscaling, and preview environments. Scale and Enterprise add organizations spanning multiple workspaces, SAML SSO, SCIM, organization-level audit logs, and Contributor, Viewer, and Billing roles. ## How does Dokploy vs Render pricing work? In September 2026, Dokploy and Render price different infrastructure layers. Dokploy's open-source self-hosted edition has no software licence fee. Enterprise Self-Hosted requires a paid licence. In either self-hosted model, you pay for servers, storage, network traffic, backup storage, monitoring, and the engineering time required to operate them. Dokploy Cloud's annual rates start at $4.50 per connected server per month for Hobby. Startup starts at $15 per month and includes three connected servers, with additional servers priced separately. Enterprise pricing is custom. Render Hobby has no workspace subscription and is limited to one member and 25 services. Pro costs $25 per workspace per month, Scale costs $499, and Enterprise uses custom pricing. Compute is charged separately and prorated to the second. Persistent disks cost $0.25 per GB per month, while outbound bandwidth is charged after the allowance included with the workspace plan. Preview resources and scaled instances add compute and datastore usage while they run. **If total operational cost is more important than the lowest platform subscription, Northflank changes the comparison.** Its free Developer Sandbox includes always-on compute for two services, one database, and two cron jobs, while pay-as-you-go has no seat fees and is prorated to the second. BYOC combines direct cloud-provider billing with Northflank platform charges, and Enterprise pricing supports volume discounts and annual commitments. Compare these costs with the infrastructure, databases, autoscaling, observability, support, and engineering work involved in running Dokploy or Render. [See Northflank pricing details](https://northflank.com/pricing). ## How does Northflank compare with Dokploy and Render? Northflank combines a managed application platform with managed-cloud and customer-cloud infrastructure. With Northflank Cloud or BYOC, Northflank operates the deployment layer and Kubernetes infrastructure. [Northflank Cloud](https://northflank.com/cloud/northflank) runs your workloads on managed infrastructure. If applications must run in your own cloud account and VPC, [self-serve BYOC](https://northflank.com/features/bring-your-own-cloud) lets you connect a supported cloud account and deploy a Northflank-managed Kubernetes cluster. You keep the cloud-provider relationship, network, resource choices, and infrastructure bill while Northflank handles cluster provisioning, upgrades, scaling, and maintenance. The same deployment workflows apply across Northflank Cloud and BYOC. If you already operate a suitable Kubernetes cluster, [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok) connects it to Northflank. Your team remains responsible for provisioning the cluster, upgrading Kubernetes, managing nodes, and scaling the underlying infrastructure, while Northflank manages its installed platform components and workload orchestration. The workload model covers [services](https://northflank.com/docs/v1/application/run/run-an-image-continuously), one-off and scheduled [jobs](https://northflank.com/docs/v1/application/run/run-an-image-once-or-on-a-schedule), and [managed databases, caches, and queues](https://northflank.com/docs/v1/application/databases-and-persistence/deploy-a-database). Northflank manages the database runtime and provides backup and restore workflows. Your team still configures retention, tests recovery, and plans disaster recovery. For development workflows, [preview environments](https://northflank.com/product/preview-environments) can reproduce services, jobs, databases, volumes, routes, and configuration for a branch or pull request, then remove the resources automatically. [Horizontal autoscaling](https://northflank.com/docs/v1/application/scale/autoscale-deployments) adjusts instances from resource metrics, while vertical scaling and BYOC node pools cover resource and infrastructure changes. Northflank also supports [GPU workloads](https://northflank.com/product/gpu-paas) alongside CPU services, jobs, and managed data for applications that include inference or other accelerated processing. For larger organizations, [Northflank Enterprise](https://northflank.com/enterprise) adds SAML or OIDC SSO, directory synchronization, granular RBAC, audit logs, policy controls, HA/DR options, 24/7 support, and custom SLAs. BYOC, BYOK, private networking, and supported on-premises deployments provide additional control over residency and infrastructure boundaries. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss application architecture, BYOC, migration, security, or compliance requirements. ## Frequently asked questions about Dokploy vs Render ### Is Dokploy better than Render? It depends on the operating model you want. Dokploy gives you an open-source deployment layer on your servers. Render provides a managed platform and workload infrastructure. ### Does Render support Docker Compose? Render Blueprints can define a multi-resource application, but they are not Docker Compose files. Dokploy can deploy Docker Compose and Docker Stack definitions directly. ### Which platform handles databases? Dokploy runs database containers on your servers and provides backup workflows. Render offers managed Postgres and Key Value. Northflank provides managed databases, caches, and queues alongside services and jobs. ### Is Dokploy cheaper than Render? Dokploy can have a lower software fee, but its total cost includes infrastructure and operations. Render combines a workspace plan with compute and usage charges. Compare a complete workload over the same period. ## Related articles about deployment platforms - [Top Dokploy alternatives for deploying applications](https://northflank.com/blog/dokploy-alternatives) - [Northflank vs Render](https://northflank.com/blog/northflank-vs-render) - [BYOC vs self-hosting vs managed cloud](https://northflank.com/blog/byoc-vs-self-hosting-vs-managed-cloud)

Dokploy vs Heroku: which deployment platform should you choose?

2026-09-11T16:09:00.000Z

Dokploy and Heroku both reduce the work involved in deploying applications, but they place the infrastructure boundary in different places. Dokploy gives you an open-source control plane for Docker workloads on servers you supply. Heroku runs applications as dynos on a managed runtime operated by Heroku. ## TL;DR: Dokploy vs Heroku - **Dokploy** is a self-hostable Docker platform with Git deployments, Compose, databases, previews, jobs, remote servers, and Docker Swarm. Your team operates the infrastructure. - **Heroku** is a managed platform built around apps, dynos, buildpacks, Pipelines, Review Apps, data services, and add-ons. - **The main decision is operational ownership.** Dokploy exposes the server and Docker environment. Heroku manages the runtime within its own infrastructure model. - **We recommend Northflank for teams that want managed application delivery with more infrastructure flexibility.** It runs services, jobs, managed databases, full-stack previews, autoscaled workloads, and GPUs on Northflank Cloud or in your own cloud account through self-serve BYOC. If you want Dokploy's infrastructure control and Heroku's managed application experience in one platform, [Northflank](https://northflank.com/) provides managed Kubernetes infrastructure and application workflows. Run services, jobs, [managed databases](https://northflank.com/features/databases), [full-stack preview environments](https://northflank.com/product/preview-environments), persistent storage, and CPU or [GPU workloads](https://northflank.com/product/gpu-paas) with integrated scaling, observability, secrets, and RBAC. Use [Northflank Cloud](https://northflank.com/cloud/northflank) for provider-managed infrastructure, or [self-serve BYOC](https://northflank.com/features/bring-your-own-cloud) to run workloads in your own cloud account and VPC while Northflank provisions and manages Kubernetes. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss migration, security, compliance, or infrastructure requirements. ## Dokploy vs Heroku at a glance | Requirement | Dokploy | Heroku | Northflank | | --- | --- | --- | --- | | Best for | Running Docker applications on servers your team selects and operates | Deploying applications through a managed app-and-dyno platform | Running production services, jobs, data, previews, and CPU or GPU workloads on managed or customer-cloud infrastructure | | Operating model | Self-hosted or managed control plane with workloads on your servers | Managed platform and Heroku-operated runtime | Managed application platform and Kubernetes orchestration across Northflank Cloud or self-serve BYOC | | Deployment sources | GitHub, Git, Docker images, Dockerfiles, buildpacks, static builds, and Docker Compose | Git, GitHub, Cloud Native Buildpacks, API, and Cedar container deployments | Git, Dockerfiles, buildpacks, registries, UI, API, CLI, GitOps, and templates | | Workloads | Applications, Compose projects, databases, scheduled jobs, and templates | Web, worker, and custom dyno processes; one-off dynos; scheduled tasks; data services and add-ons | Services, workers, one-off and scheduled jobs, managed databases, caches, queues, volumes, and CPU or GPU containers | | Preview environments | GitHub pull-request previews for applications | GitHub Review Apps through Pipelines, with declared add-ons | Full-stack previews with services, jobs, databases, volumes, networking, seed workflows, and automated teardown | | Scaling | Server sizing, remote-server placement, or replicas through Docker Swarm | Dyno sizing and quantity, with native autoscaling for eligible Cedar web dynos | Horizontal autoscaling using CPU, memory, requests, or custom metrics; configurable vertical scaling and BYOC node-pool controls | | Data | PostgreSQL, MySQL, MariaDB, MongoDB, and Redis containers on your servers | Heroku Postgres, Heroku Key-Value Store, Apache Kafka on Heroku, and marketplace add-ons | Managed databases, caches, queues, backups, replicas, and high-availability options | | Infrastructure choice | Compatible customer-supplied Linux servers | Heroku-operated Common Runtime or Private Spaces | Northflank Cloud or Northflank-managed Kubernetes in your cloud account and VPC | | Enterprise controls | Enterprise editions add custom roles, SSO, SCIM, audit logs, and SLA options | Heroku no longer offers new Enterprise Account contracts; Existing Enterprise customers can use teams, SSO, app permissions, audit trails, Private Spaces, and Shield options | Granular RBAC, SSO, directory sync, audit logs, policy controls, workload identities, HA/DR options, 24/7 support, and custom SLAs | | Pricing model | Free open-source self-hosting or annual Cloud plans from $4.50 per connected server per month, plus infrastructure | Dynos, data services, add-ons, and private runtime resources priced separately | Free Developer Sandbox, per-second pay-as-you-go without seat fees, BYOC platform charges, or custom Enterprise pricing | ## What are the main differences between Dokploy and Heroku? Dokploy exposes servers, Docker, and placement decisions. Heroku abstracts those details behind apps, process types, and dynos. ### Deployment architecture and workflow Dokploy installs on a compatible Linux server and uses Docker, Docker Swarm, and Traefik. It can run everything on one server, connect independent remote deployment servers over SSH, or replicate applications across Swarm nodes. Multi-node Swarm deployments require a Docker registry and cluster operations. Independent remote servers do not form a shared cluster. Applications deploy from GitHub, generic Git repositories, or Docker images. Dokploy supports Dockerfiles, buildpacks, static builds, webhooks, Docker Compose, Docker Stack, and templates. Heroku builds applications from Git, GitHub, or API deployments and runs web, worker, or custom processes in dynos. Supported languages can use maintained Cloud Native Buildpacks. Pipelines group environments and promote the same build between stages. Heroku supports container deployments for Cedar-generation applications. Fir takes a different route, using Cloud Native Buildpacks to produce OCI-compatible images. ### Environments and previews Dokploy creates isolated previews for GitHub pull requests. The preview limit is configurable for each application and defaults to three. Previews update with new commits and are removed when the pull request closes or merges. Connected databases or other resources need their own lifecycle design. Heroku Review Apps create disposable applications from GitHub pull requests through Heroku Pipelines. They can include declared add-ons and setup tasks. Automatically created Review Apps are removed when a pull request closes, and their dynos and add-ons are billed like normal resources. ### Databases and persistent storage Dokploy supplies lifecycle and backup workflows for PostgreSQL, MySQL, MariaDB, MongoDB, and Redis containers. They run on your servers, so your team owns capacity, upgrades, backups, restore tests, security, and availability. Heroku provides Heroku Postgres, Heroku Key-Value Store, and Apache Kafka on Heroku, alongside third-party marketplace add-ons. Dyno filesystems are ephemeral and not shared, so persistent application state belongs in a data service or another backing service. Dokploy gives you tooling around database containers you operate. Heroku sells managed data services with plan-specific capacity, backup, and support features. ### Networking and scaling Dokploy uses Traefik for domains, routing, and automatic HTTPS. Teams can scale servers vertically, distribute applications across remote servers, or run replicas through Docker Swarm. High availability still requires deliberate state, failure-domain, capacity, and recovery design. Heroku applications scale by changing dyno quantity or size for each process type. On Cedar, eligible Performance, Private, and Shield web dynos can autoscale against a target p95 response time. Native autoscaling is not currently available on Fir. Eco and Basic allow one dyno per process type, while higher tiers expand scaling and runtime options. Cedar Private Spaces add isolated networking, stable outbound IPs, optional internal routing, AWS VPC peering, and VPN connectivity. Private Space peering connects Heroku infrastructure to an AWS VPC; it does not move dynos into the customer's cloud account. ### Operations and enterprise controls Self-hosted Dokploy leaves upgrades, server patching, networking, storage, and disaster recovery with your team. Dokploy Cloud manages the control plane, but workloads still run on your servers. Heroku operates its control plane and runtime. Customers remain responsible for code, configuration, access, data, and attached services. Dokploy includes basic roles and two-factor authentication, while Enterprise Self-Hosted and Enterprise Cloud add fine-grained roles, OIDC or SAML SSO, SCIM, audit logs, and commercial support options. Heroku requires MFA for all customers, while organisations using SSO enforce MFA through their identity provider. Existing Enterprise customers can use Enterprise Accounts and Teams, SSO, application permissions, Private Spaces, and audit trails. Shield Private Spaces and Shield data plans add controls for eligible regulated workloads. Heroku stopped offering new Enterprise Account contracts in February 2026. Existing Enterprise subscriptions and support contracts can renew. ## How does Dokploy vs Heroku pricing work? Dokploy and Heroku prices cover different infrastructure layers, so their entry prices do not tell the whole story. - **Dokploy:** The open-source self-hosted edition has no software licence fee. On annual billing, Dokploy Cloud Hobby starts at $4.50 per connected server per month. Startup starts at $15 per month and includes up to three connected servers. Servers, storage, traffic, backups, monitoring services, and infrastructure operations remain additional costs. - **Heroku:** Eco provides personal apps with 1,000 shared dyno hours for $5 per month. An Eco web app sleeps after 30 minutes without web traffic, while a worker-only app does not automatically sleep. Example Cedar-generation prices are Basic at up to $7 per dyno per month, Standard-1X at up to $25, Standard-2X at up to $50, Performance-M at up to $250, and Performance-L at up to $500. Usage is generally prorated to the second, except the full Eco subscription. Fir dynos and Private Spaces use separate pricing. Data services, add-ons, CI usage, and the dynos and add-ons in Review Apps add further consumption charges. Dokploy's total cost includes infrastructure and engineering retained by your team. Heroku bundles more runtime operations into its service, while application topology and add-ons determine the bill. **If total operational cost matters more than the lowest entry price, Northflank changes the comparison.** Its free Developer Sandbox includes always-on compute for two services, one database, and two cron jobs, while pay-as-you-go has no seat fees and is prorated to the second. BYOC combines direct cloud-provider billing with Northflank platform charges, and Enterprise pricing supports volume discounts and annual commitments. Compare these costs with Heroku's dynos, data services, add-ons, private runtime resources, and retained engineering work. [See Northflank pricing details](https://northflank.com/pricing). ## How does Northflank compare with Dokploy and Heroku? [Northflank Cloud](https://northflank.com/cloud/northflank) runs workloads on managed infrastructure. With [self-serve BYOC](https://northflank.com/features/bring-your-own-cloud), Northflank provisions and manages Kubernetes in your AWS, GCP, Azure, or other supported cloud account. Your organisation retains its VPC, cloud bill, commitments, and capacity choices, while developers use the same workflows. Those workflows cover [services](https://northflank.com/docs/v1/application/run/run-containers-and-micro-services), workers, [one-off and scheduled jobs](https://northflank.com/docs/v1/application/run/run-an-image-once-or-on-a-schedule), and [managed databases](https://northflank.com/features/databases), caches, and queues. Teams can create [full-stack previews](https://northflank.com/product/preview-environments) with services, jobs, databases, volumes, secrets, private networking, and automated cleanup. Northflank supports [horizontal autoscaling](https://northflank.com/docs/v1/application/scale/autoscale-deployments) using CPU, memory, requests per second, or custom Prometheus metrics. [GPU services and jobs](https://northflank.com/product/gpu-paas) can run on Northflank Cloud or compatible BYOC GPU node pools. Northflank includes granular RBAC and secret management. [Enterprise](https://northflank.com/enterprise) adds governance and support options including SAML or OIDC SSO, directory sync, audit logs, policy controls, workload identities, high-availability and disaster-recovery options, 24/7 support, and custom SLAs. Customer-cloud, eligible on-premises, and private deployment options support teams with stricter networking, data-boundary, or compliance requirements. We recommend Northflank when you want developer self-service without choosing between a self-operated Docker platform and a vendor-operated runtime. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss migration, security, compliance, or infrastructure requirements. ## Frequently asked questions about Dokploy vs Heroku ### Is Dokploy a Heroku alternative? Yes, for teams prepared to supply and operate servers. Dokploy recreates many PaaS workflows on Docker infrastructure you control, while Heroku provides the runtime as a managed service. ### Does Dokploy manage servers for you? No. Dokploy Cloud manages the control plane, but your connected servers run the workloads. Self-hosting also leaves the control plane with your team. ### Can Heroku run Docker containers? Yes. Cedar-generation apps can deploy container images through Heroku Container Registry. Fir builds OCI-compatible images with Cloud Native Buildpacks. ### Which platform handles databases? Dokploy runs database containers on your servers. Heroku offers managed data services and add-ons. Northflank provides managed databases, caches, and queues on Northflank Cloud and BYOC. ### Which platform supports preview environments? Dokploy provides GitHub pull-request previews for applications. Heroku Review Apps create disposable pipeline apps and can provision declared add-ons. Northflank Preview Blueprints can reproduce a connected stack of services, jobs, databases, volumes, and networking. ### Which is cheaper, Dokploy or Heroku? It depends on workload usage and operational cost. Include Dokploy's servers and maintenance, or Heroku's dynos, data services, add-ons, and private resources, rather than comparing only entry prices. ### When should I use Northflank instead? Use Northflank when you need managed services, jobs, databases, full-stack previews, autoscaling, GPU workloads, and a choice between managed infrastructure and self-serve BYOC. ## Related articles about deployment platform selection - [Top Dokploy alternatives for deploying applications](https://northflank.com/blog/dokploy-alternatives) - [Northflank vs Heroku](https://northflank.com/blog/northflank-vs-heroku) - [BYOC vs self-hosting vs managed cloud](https://northflank.com/blog/byoc-vs-self-hosting-vs-managed-cloud) - [Northflank vs Railway](https://northflank.com/blog/northflank-vs-railway) - [How to replace a DIY internal developer platform](https://northflank.com/blog/replace-diy-internal-developer-platform)

Dokploy vs Coolify: which deployment platform should you choose?

2026-09-10T15:40:00.000Z

Dokploy and Coolify both turn your own servers into application deployment platforms. The decision depends on how you want to scale across servers, which deployment and database workflows you need, and whether a hosted option should manage only the control plane or more of the infrastructure. This comparison covers architecture, deployments, scaling, databases, backups, team controls, pricing, and operational responsibility. ## TL;DR: Dokploy vs Coolify Dokploy and Coolify cover many of the same Docker deployment workflows, but they diverge on scaling, feature packaging, and how much of the platform your team operates. - **Dokploy** suits teams that want a choice between one server, independent remote servers, and a Docker Swarm cluster. It also provides application, Compose, server, and Dokploy-container scheduled jobs, plus paid hosted plans. - **Coolify** suits teams that want a free, open-source control plane with applications, Docker Compose, one-click services, a broad selection of databases, and no features reserved for Coolify Cloud. - **Both platforms** deploy Docker workloads to selected servers and support Git-based delivery, container images, Docker Compose, domains, TLS, previews, logs, monitoring, APIs, and persistent storage. Your team still needs to account for server security, storage, networking, backups, and recovery. - **Northflank** is the recommended option when you need a managed application platform rather than a control plane over servers your team still operates. It runs complete stacks on Northflank Cloud or in your own cloud account through self-serve BYOC. If you like the infrastructure control of Dokploy or Coolify but do not want to operate the deployment layer yourself, [Northflank](https://northflank.com/) provides managed Kubernetes infrastructure and application workflows in one platform. Run services, jobs, [managed databases](https://northflank.com/features/databases), [full-stack preview environments](https://northflank.com/product/preview-environments), persistent storage, and CPU or [GPU workloads](https://northflank.com/product/gpu-paas) with integrated scaling, observability, secrets, and RBAC. Use [Northflank Cloud](https://northflank.com/cloud/northflank) for provider-managed infrastructure, or [self-serve BYOC](https://northflank.com/features/bring-your-own-cloud) to run workloads in your own cloud account and VPC while Northflank provisions and manages Kubernetes. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss migration, security, compliance, or infrastructure requirements. ## Dokploy vs Coolify at a glance The largest differences are multi-server orchestration, hosting scope, and feature packaging. | Platform | Dokploy | Coolify | Northflank | | --- | --- | --- | --- | | Best for | Running Docker applications across your own servers, including Docker Swarm | Running an open-source Docker deployment control plane on user-supplied servers | Running production services, jobs, databases, previews, and CPU or GPU workloads on managed or customer-cloud infrastructure | | Runtime and orchestration | Docker on one server, independent remote servers, or Docker Swarm nodes | Docker on standalone servers; experimental multi-server and Swarm options | Managed Kubernetes on Northflank Cloud or in your own cloud account through BYOC | | Hosting model | Self-hosted or Dokploy-managed control plane with workloads on your servers | Self-hosted or Coolify-managed control plane with workloads on your servers | Managed infrastructure or Northflank-managed Kubernetes in your cloud account and VPC | | Deployment sources | GitHub, Git, Docker images, Dockerfile, buildpacks, Railpack, Nixpacks, static builds, and Docker Compose | Public or private Git, Docker images, Dockerfile, Nixpacks, Railpack (beta), static builds, and Docker Compose | Git repositories, Dockerfiles, buildpacks, external container registries, UI, API, CLI, GitOps, and templates | | Scaling | Vertical server scaling, independent placement, or application replicas through Docker Swarm | Vertical scaling or experimental multi-server deployment with a separately configured load balancer | Horizontal autoscaling and configurable vertical scaling, with BYOC node-pool controls | | Data and backups | Five built-in database types, persistent volumes, database backups, and named-volume backups | Eight built-in database types; scheduled backup workflows for PostgreSQL, MySQL, MariaDB, and MongoDB | Managed databases, caches, queues, persistent volumes, backups, replicas, and high-availability options | | Team controls | Basic roles in OSS and Cloud; custom roles, SSO, SCIM, and audit logs in Enterprise editions | Owner, Admin, and mostly read-only Member roles in the open-source product | RBAC and secret management on all plans; Enterprise SSO, directory sync, audit logs, policy controls, and workload identities | | Pricing model | Free self-hosting or annual Cloud plans from $4.50 per server per month | Free self-hosting or monthly Cloud pricing from $5 per team for two connected servers, then $3 per additional server | Free Developer Sandbox, per-second pay-as-you-go without seat fees, or custom Enterprise pricing | ## What do Dokploy and Coolify have in common? Dokploy and Coolify both deploy containerised applications from Git repositories, Dockerfiles, images, and Docker Compose. Their dashboards cover configuration, domains, certificates, logs, storage, databases, previews, and deployments. Self-hosting either product leaves your team responsible for the servers, networking, security, upgrades, backups, and recovery. Their Cloud products manage the control plane, while applications and databases continue to run on servers you supply. ## What are the main differences between Dokploy and Coolify? The main differences are multi-server scaling, build options, database coverage, backups, and team controls. ### Deployment architecture and scaling Dokploy can run the control plane and workloads on one server, deploy to independent remote servers over SSH, or replicate applications across Docker Swarm nodes. Swarm requires compatible node architectures, a shared registry, and cluster operations. Coolify offers experimental multi-server and Docker Swarm features. Its multi-server workflow deploys one image to matching standalone servers, but your team configures the external load balancer. Both products therefore add registry, networking, storage, and recovery work as deployments expand beyond one server. ### Application delivery and developer workflow Both platforms deploy from Git, Dockerfiles, Compose definitions, and container images, support pull-request previews, and can move builds to dedicated servers. Dokploy also offers Nixpacks, Railpack, Heroku and Paketo buildpacks, and static builds; its remote build servers exclude Compose deployments. Coolify offers Nixpacks and Railpack in beta for Git-based deployments, plus one-click service templates. Dokploy uses Traefik, while Coolify defaults to Traefik and offers Caddy experimentally. Both provide APIs and scheduled commands. Dokploy jobs can target applications, Compose containers, remote hosts, or the Dokploy container, while Coolify tasks target resources or servers. ### Databases, persistence, and backups Coolify offers eight one-click database engines, compared with five on Dokploy. These are self-operated containers rather than managed database services. Coolify schedules backups for PostgreSQL, MySQL, MariaDB, and MongoDB, with S3-compatible storage available; ClickHouse uses a separate S3 procedure. Its control-plane backup excludes application volumes. Dokploy schedules database and Docker named-volume backups, but not bind-mount backups. Either way, your team owns retention, failure monitoring, and restore testing. ### Teams and enterprise controls Coolify provides Owner, Admin, and mostly read-only Member roles. Dokploy Self-Hosted OSS and Cloud also include basic roles, while Cloud plan limits determine user and organisation allowances. Dokploy Enterprise Self-Hosted and Enterprise Cloud add custom roles, OIDC or SAML SSO, SCIM, and audit logs. Enterprise Cloud also includes managed control-plane uptime, automatic updates, priority support, and an SLA. Larger teams should compare permissions, identity integration, audit coverage, and support rather than role names alone. ## How does Dokploy vs Coolify pricing work? Dokploy and Coolify can both be self-hosted without a software licence fee, but the hosted products use different commercial models. Prices below were checked on 10 September 2026. - **Dokploy:** Annual pricing starts at $4.50 per server per month for Hobby or $15 per month for Startup with three servers. Additional servers cost $4.50 per month. Enterprise is contact-led. - **Coolify:** Monthly Cloud pricing starts at $5 per team for two connected servers and $3 per additional server. Additional teams need separate subscriptions. Annual billing saves 20%, and workload servers cost extra. **If total operational cost is more important than the lowest platform subscription, Northflank changes the comparison.** Its free Developer Sandbox includes always-on compute for two services, one database, and two cron jobs, while pay-as-you-go has no seat fees and is prorated to the second. BYOC combines direct cloud-provider billing with Northflank platform charges, and Enterprise pricing supports volume discounts and annual commitments. Compare these costs with the servers, orchestration, databases, autoscaling, observability, support, and engineering work retained when running Dokploy or Coolify. [See Northflank pricing details](https://northflank.com/pricing). ## How does Northflank compare with Dokploy and Coolify? Northflank takes a different approach from Dokploy and Coolify by combining application delivery, managed infrastructure, Kubernetes orchestration, and production operations in one platform. Teams can use it for anything from an individual service to complete application stacks across managed or customer-owned cloud infrastructure. [Northflank Cloud](https://northflank.com/features/managed-cloud) runs workloads on managed infrastructure. With [bring your own cloud](https://northflank.com/features/bring-your-own-cloud), Northflank provisions and manages Kubernetes in your cloud account while you retain your provider relationship, network, capacity choices, and cloud bill. Developers use the same services, jobs, databases, templates, and release workflows across both models. Northflank also covers workload requirements that can otherwise add separate systems to a self-hosted Docker platform: [managed databases and queues](https://northflank.com/features/databases), [automated full-stack previews](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints), [horizontal autoscaling](https://northflank.com/docs/v1/application/scale/autoscale-deployments), configurable vertical scaling, integrated logs and metrics, and CPU or GPU workloads. Northflank Enterprise adds SAML or OIDC SSO, directory sync, granular RBAC, audit logs, policy controls, high-availability and disaster-recovery options, and 24/7 support with custom SLAs. It also supports regulated and private deployment requirements, including workloads in your own VPC and eligible on-premises Kubernetes environments. This makes Northflank the recommended route when the team needs a production platform with developer self-service and enterprise governance, while still retaining the choice between managed infrastructure and its own cloud account. Compare that managed boundary with the full infrastructure and engineering cost of operating Dokploy or Coolify. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss a production or BYOC architecture. ## Frequently asked questions about Dokploy vs Coolify ### Is Dokploy better than Coolify? It depends on your deployment model. Dokploy provides a direct Docker Swarm path, while Coolify offers an unrestricted open-source feature set and more built-in database engines. Northflank is the recommended option when you want managed infrastructure or BYOC with Kubernetes managed for you. ### Are Dokploy and Coolify open source? Yes. Both can be self-hosted without a software licence fee. Infrastructure, storage, networking, backups, maintenance, and engineering time still create costs. ### Does Coolify Cloud host your applications? No. Coolify Cloud manages the control plane while your servers run the workloads. Dokploy Cloud follows the same broad model. Northflank Cloud also manages the workload infrastructure, while Northflank BYOC manages Kubernetes in your cloud account. ### Can Dokploy and Coolify scale across multiple servers? Yes. Dokploy uses remote servers or Docker Swarm, while Coolify's multi-server and Swarm options are experimental. Northflank provides Kubernetes orchestration and horizontal autoscaling without requiring your team to assemble the same scaling layer. ### Which is cheaper, Dokploy or Coolify? Both are free to self-host. Coolify Cloud starts at $5 per team per month, while Dokploy Cloud's annual Hobby price starts at $4.50 per server per month. Compare those fees and server costs with Northflank's usage-based pricing and broader managed-infrastructure scope. ## Related articles about deployment platform selection - [Top Dokploy alternatives for deploying applications](https://northflank.com/blog/dokploy-alternatives) - [BYOC vs self-hosting vs managed cloud](https://northflank.com/blog/byoc-vs-self-hosting-vs-managed-cloud) - [How to replace a DIY internal developer platform](https://northflank.com/blog/replace-diy-internal-developer-platform) - [Northflank vs Railway](https://northflank.com/blog/northflank-vs-railway) - [Northflank vs Render](https://northflank.com/blog/northflank-vs-render)

Dokploy vs Railway: which deployment platform should you choose?

2026-09-10T15:02:00.000Z

Dokploy and Railway both simplify application deployment, but they give your team different infrastructure responsibilities. Dokploy runs a deployment control plane over servers you supply, while Railway's standard path combines the application platform and workload infrastructure as a managed service. This comparison covers architecture, deployments, environments, databases, scaling, team controls, pricing, and operational responsibility. ## TL;DR: Dokploy vs Railway The Dokploy vs Railway decision depends on whether you want to operate your own servers or use provider-managed infrastructure. - **Dokploy** provides an open-source, Docker-based control plane on selected servers, with Compose, databases, previews, remote servers, and Swarm clusters. - **Railway** deploys from GitHub, its CLI, or Docker images onto managed infrastructure, with environments, volumes, private networking, and replicas. - **The operating boundary is the main difference.** Self-hosted Dokploy leaves the control plane and servers with your team. Dokploy Cloud manages the control plane, but your servers still run the workloads. Railway manages both on its standard path. - **Northflank** combines application delivery, managed Kubernetes infrastructure, and production operations. Teams can run services, jobs, managed databases, full-stack previews, and CPU or GPU workloads on Northflank Cloud, in their own cloud account through self-serve BYOC, or on eligible Kubernetes infrastructure through BYOK. If you need infrastructure choice without operating the deployment layer, [Northflank](https://northflank.com/) provides services, jobs, [managed databases](https://northflank.com/features/databases), [full-stack previews](https://northflank.com/product/preview-environments), storage, and CPU or [GPU workloads](https://northflank.com/product/gpu-paas) with scaling, observability, secrets, and RBAC. Use [Northflank Cloud](https://northflank.com/cloud/northflank) or [self-serve BYOC](https://northflank.com/features/bring-your-own-cloud), which places Northflank-managed Kubernetes in your cloud account and VPC. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss migration, security, compliance, or infrastructure requirements. ## Dokploy vs Railway at a glance The platforms overlap on application delivery, but differ substantially in workload scope, orchestration, and infrastructure ownership. | Platform | Dokploy | Railway | Northflank | | --- | --- | --- | --- | | Best for | Running Docker applications on servers your team selects and operates | Deploying applications quickly on provider-managed infrastructure | Running production services, jobs, databases, previews, and CPU or GPU workloads on managed or customer-cloud infrastructure | | Operating model | Self-hosted or Dokploy-managed control plane with workloads on your servers | Managed application platform and standard workload infrastructure | Managed application platform and Kubernetes orchestration across Northflank Cloud, BYOC, or eligible BYOK infrastructure | | Deployment sources | Git, Docker images, Dockerfiles, buildpacks, static builds, and Docker Compose | GitHub, CLI deployments, Docker images, Dockerfiles, and Railpack | Git, Dockerfiles, buildpacks, registries, UI, API, CLI, GitOps, and templates | | Workload scope | Applications, Compose projects, databases, scheduled jobs, and templates | Persistent services, cron schedules, Functions, database templates, and volumes | Services, jobs, managed databases, caches, queues, volumes, object storage, and CPU or GPU workloads | | Preview environments | GitHub pull-request previews for applications | Pull-request environments copied from a base environment | Full-stack previews with services, jobs, databases, volumes, networking, and automated teardown | | Scaling | Vertical server scaling, remote-server placement, or replicas through Docker Swarm | Vertical resources, replicas, and multi-region deployment within plan limits | Horizontal autoscaling, configurable vertical scaling, and BYOC node-pool controls | | Databases and persistence | Database containers and persistent storage on your servers | Unmanaged database templates on persistent volumes, with platform backup tooling | Managed databases, caches, queues, volumes, backups, replicas, and high-availability options | | Infrastructure choice | Compatible customer-supplied Linux servers | Railway-managed infrastructure | Northflank Cloud, self-serve BYOC, or eligible existing Kubernetes through BYOK | | Team and enterprise controls | Basic roles and 2FA; Enterprise editions add custom roles, SSO, SCIM, and audit logs | Logs, metrics, audit logs, and plan-based access controls | RBAC and secrets; Enterprise adds SSO, directory sync, audit logs, policy controls, HA/DR options, 24/7 support, and custom SLAs | | Pricing model | Free self-hosting or annual Cloud plans from $4.50 per connected server per month, plus infrastructure | Plan minimum with included usage, followed by usage-based compute, storage, and egress | Free Developer Sandbox, per-second pay-as-you-go without seat fees, BYOC platform charges, or custom Enterprise pricing | ## What are the main differences between Dokploy and Railway? Dokploy exposes more of the server and Docker operating model, while Railway absorbs more infrastructure work into its managed platform. ### Deployment architecture and workflow Dokploy can run its control plane, builds, and applications on one Linux server, use independent remote servers over SSH, or replicate applications across Docker Swarm nodes. Swarm requires compatible nodes, a shared registry, networking, capacity, and cluster operations. Applications deploy from GitHub, generic Git repositories, or Docker images. Dokploy also supports Dockerfiles, buildpacks, static builds, webhooks, health checks, custom commands, Docker Compose, and Docker Stack. Railway deploys from GitHub, its CLI, or a Docker image using Railpack or a Dockerfile. It supports monorepos, private registries, health checks, restart policies, cron schedules, and Functions. Dokploy requires a compatible server and platform installation, even when Dokploy Cloud hosts the control plane. Railway creates services inside a managed project without requiring the application team to prepare hosts. ### Environments and previews Dokploy supports pull-request previews for GitHub-connected applications. The maximum is configurable per application and defaults to three. Railway environments isolate service instances and variables. Pull-request environments copy a base environment and are removed when the pull request closes or merges, allowing previews to reproduce several connected services. ### Databases and persistent storage Dokploy provides PostgreSQL, MySQL, MariaDB, MongoDB, and Redis on customer-supplied servers. Your team remains responsible for storage, capacity, backup destinations, restore testing, security, and availability. Railway's PostgreSQL, MySQL, MongoDB, and Redis templates are unmanaged services. Railway operates the platform and provides backup tooling, but your team owns configuration, security, monitoring, tuning, backups, and disaster recovery. PostgreSQL, MySQL, and Redis HA templates require deliberate selection rather than applying automatically. ### Networking and scaling Dokploy uses Traefik for routing, domains, and automatic HTTPS. Remote servers can separate workloads, while horizontal replicas use Docker Swarm. Swarm is not a complete HA design without suitable failure domains, capacity, storage, monitoring, and recovery. Railway services in the same project environment communicate privately over encrypted WireGuard tunnels and internal DNS. Railway supports public domains, vertical scaling, replicas, and multi-region placement within plan limits. Services with volumes cannot use replicas, and redeploying a volume-backed service involves some downtime. Horizontally scaled applications and persistent state therefore need separate designs. ### Infrastructure and operational responsibility Self-hosted Dokploy leaves the control plane and infrastructure with your team. Dokploy Cloud manages the control plane, but connected customer-supplied servers still run applications and databases. Railway manages its control plane and workload infrastructure, so application teams deploy within Railway's regions, resource limits, and platform configuration instead of maintaining hosts. ## How does Dokploy vs Railway pricing work? As of 10 September 2026, Dokploy and Railway use different commercial models because their standard products manage different infrastructure layers. - **Dokploy:** The open-source edition has no software licence fee. Annual Dokploy Cloud pricing starts at $4.50 per server per month for Hobby, including management of one connected server, or $15 per month for Startup, including up to three connected servers. Workload servers, storage, traffic, backups, monitoring, and engineering operations remain additional costs. - **Railway:** Free includes $1 of monthly resources. Hobby costs $5 per month with $5 of included usage, and Pro costs $20 with $20 of included usage. Standard rates are $10 per GB of RAM per month, $20 per vCPU per month, $0.15 per GB of volume storage per month, and $0.05 per GB of egress. Enterprise pricing is custom. Total cost depends on infrastructure usage and operational work. Dokploy can reduce software spend, while Railway can reduce engineering overhead by managing the platform and hosts. **If total operational cost is more important than the lowest platform subscription, Northflank changes the comparison.** Its free Developer Sandbox includes always-on compute for two services, one database, and two cron jobs, while pay-as-you-go has no seat fees and is prorated to the second. BYOC retains direct cloud-provider billing and adds Northflank platform charges; Enterprise supports custom pricing and volume discounts. Compare infrastructure, databases, autoscaling, observability, support, and engineering operations. [See Northflank pricing details](https://northflank.com/pricing). ## How does Northflank compare with Dokploy and Railway? Northflank combines application delivery, managed infrastructure, Kubernetes orchestration, and production operations in one platform, from individual services to complete stacks across managed or customer-owned cloud infrastructure. [Northflank Cloud](https://northflank.com/cloud/northflank) runs workloads on managed infrastructure. With [bring your own cloud](https://northflank.com/features/bring-your-own-cloud), Northflank manages Kubernetes in your cloud account and VPC while you retain your provider relationship, network, capacity choices, and cloud bill. Developers use the same workflows across both models. [Bring Your Own Kubernetes](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements) connects eligible Kubernetes infrastructure, including supported private and on-premises environments. BYOK should use a new, dedicated cluster rather than one already running production or shared workloads, and the cluster must meet the required Kubernetes, networking, storage, and component specifications. The platform includes [managed databases and queues](https://northflank.com/features/databases), [full-stack previews](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints), [horizontal autoscaling](https://northflank.com/docs/v1/application/scale/autoscale-deployments), vertical scaling, logs and metrics, storage, and CPU or GPU workloads. Northflank Enterprise adds SAML or OIDC SSO, directory sync, granular RBAC, audit logs, policy controls, HA/DR, and 24/7 support with custom SLAs. Private, customer-cloud, and eligible on-premises options support stricter requirements. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss a production or BYOC architecture. ## Frequently asked questions about Dokploy vs Railway ### Is Dokploy better than Railway? It depends on the deployment model. Dokploy gives your team an open-source Docker control plane on selected servers. Railway manages the standard platform and infrastructure. Northflank adds managed cloud and self-serve customer-cloud options under one application workflow. ### Does Railway require you to manage servers? Not on its standard deployment path. Railway operates the control plane and workload infrastructure. Dokploy leaves workload servers with your team, while Northflank supports managed infrastructure or Northflank-managed Kubernetes in your cloud account. ### Which platform is better for databases? Dokploy and Railway run database containers on their respective workload infrastructure, with different tooling and responsibilities. Northflank provides managed databases, caches, and queues when the platform needs to own backups, upgrades, scaling, and high-availability options. ### Which is cheaper, Dokploy or Railway? It depends on usage and operational cost. Dokploy adds customer-supplied infrastructure and maintenance to its software or Cloud fee. Railway combines plan minimums with resource usage. Northflank adds usage-based managed cloud or BYOC platform pricing for a broader managed operating scope. ### When is Northflank an alternative to Dokploy and Railway? Northflank is an alternative when you need services, jobs, managed data, full-stack previews, autoscaling, observability, and CPU or GPU workloads across managed infrastructure or your own cloud account. ## Related articles about deployment platform selection - [Top Dokploy alternatives for deploying applications](https://northflank.com/blog/dokploy-alternatives) - [Northflank vs Railway](https://northflank.com/blog/northflank-vs-railway) - [BYOC vs self-hosting vs managed cloud](https://northflank.com/blog/byoc-vs-self-hosting-vs-managed-cloud) - [Northflank vs Render](https://northflank.com/blog/northflank-vs-render) - [Northflank vs Heroku](https://northflank.com/blog/northflank-vs-heroku)

How to run browser agents in secure sandboxes on Northflank

2026-09-09T18:30:00.000Z

## TL;DR: how to run browser agents in secure sandboxes - Browser agents face a unique threat model because untrusted web content can contain prompt injection that influences the agent's actions, even when the browser itself is isolated. - Chromium's built-in process sandbox protects against certain browser and renderer exploits, but it does not control what an AI agent does with the browser's legitimate permissions. - A secure browser-agent sandbox should provide strong workload isolation, egress controls, session isolation, scoped credentials, and audit logging. - [Northflank Sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) provide microVM-backed containers with VM-level isolation, startup times under 1 second, and API-based lifecycle management for running untrusted workloads such as AI agents. - Sandboxes can run on [Northflank's managed cloud](https://northflank.com/features/managed-cloud) or [in your own cloud through BYOC](https://northflank.com/features/bring-your-own-cloud), and can be paused, resumed, or destroyed as needed. > [Get started (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > Browser agents interact with the web autonomously: navigating pages, clicking elements, filling forms, extracting data, and taking screenshots. Computer-use agents such as Claude Computer Use and ChatGPT agent, along with Playwright-based agents, can perform multi-step tasks across web applications without a human controlling every interaction. That capability is what makes browser agents useful. It also makes the browser environment a significant security boundary. The threat model for browser agents is different from the threat model for coding agents. A coding agent's primary risk comes from the code it generates and executes, while a browser agent also consumes untrusted web content that can influence its behavior. A malicious webpage can contain instructions designed to make an agent take actions outside its intended scope, such as sending sensitive data to an external endpoint or interacting with an unauthorized service. The sandbox therefore needs to isolate not only the agent's execution environment, but also the browser session and the credentials associated with it. ## What a secure browser agent sandbox requires 1. **MicroVM isolation for the browser process:** Standard containers share the host kernel, while microVM-based isolation provides a stronger boundary around the browser workload. A compromised browser process or agent workload is isolated from the underlying host and other sandbox sessions. 2. **Egress controls on what the browser can reach:** Default-deny egress means the browser can only reach destinations explicitly allowed by the network policy. If a prompt injection causes the agent to send data to an attacker-controlled domain, the request can be blocked because the destination is not in the allowlist. 3. **Session isolation between tenants:** In a multi-tenant browser agent platform, each user's session should be isolated from other users' sessions. Isolating each session at the workload or VM level reduces the risk of one compromised browser session accessing another user's browser state, files, or processes. 4. **Scoped credential injection:** Credentials required by the browser agent should come from a secrets manager and be limited to the permissions required for the task. They should be injected at runtime rather than stored in the browser image, source code, or developer's local environment. 5. **Audit logging of browser activity:** Platform-level logging should provide visibility into session creation, configuration changes, resource usage, and other relevant activity. Keeping this visibility outside the agent's own process makes it more useful when investigating unexpected behavior. ## How to run a browser agent in a Northflank sandbox Northflank Sandboxes provide isolated environments for running browser agents and browser automation workloads. They boot in under 1 second, run in their own isolated environment, and can be created and managed programmatically using the [Northflank SDK](https://northflank.com/docs/v1/api/use-the-javascript-client). Northflank is an AI-agent sandbox and workload platform for running untrusted code in isolated environments on [Northflank cloud](https://northflank.com/cloud/northflank), in [your own cloud account and VPC](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-in-your-cloud), or on [eligible on-premises infrastructure](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok). ### Prerequisites - A [Northflank account](https://app.northflank.com/signup) - An [API token](https://app.northflank.com/s/account/settings/api/tokens/new) - A [Northflank project](https://app.northflank.com/s/account/projects/new) ### Step 1: Install and initialize the SDK ```bash npm install @northflank/js-client ``` ```tsx import { ApiClient, ApiClientInMemoryContextProvider, } from "@northflank/js-client"; const contextProvider = new ApiClientInMemoryContextProvider(); await contextProvider.addContext({ name: "context", token: process.env.NORTHFLANK_TOKEN, }); const apiClient = new ApiClient(contextProvider, { throwErrorOnHttpErrorCode: true, }); ``` ### Step 2: Create a browser agent sandbox Deploy your browser agent container as a sandbox service. Northflank sandboxes provide the isolated execution environment. Your browser agent application, including the browser controller, task logic, and any policy enforcement, runs inside it. ```tsx const sandboxId = `browser-agent-${crypto.randomUUID().split("-")[4]}`; await apiClient.create.service.deployment({ parameters: { projectId: "your-project-id", }, data: { name: sandboxId, billing: { deploymentPlan: "nf-compute-200", }, deployment: { instances: 1, docker: { configType: "customCommand", customCommand: "sleep infinity", }, external: { imagePath: "your-browser-agent-image", }, storage: { ephemeralStorage: { storageSize: 4096, }, }, }, }, }) ``` For credentials, use [Northflank secret groups](https://northflank.com/docs/v1/application/secure/manage-secret-groups) rather than storing sensitive values directly in your service configuration. Before executing commands, make sure the sandbox is fully running. See the [SDK reference](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#start-the-sandbox) for how to wait for it to be ready. ### Step 3: Execute a browser task inside the sandbox Once the sandbox is running, execute your browser agent. Replace `your-browser-agent-script.js` with the entry point of your browser agent application, and make sure your image includes your script and its dependencies. ```tsx const handle = await apiClient.exec.execServiceSession( { projectId: "your-project-id", serviceId: sandboxId, }, { shell: "bash -c", command: "node your-browser-agent-script.js", } ); const result = await handle.waitForCommandResult(); console.log("Exit code:", result.exitCode); ``` The browser process runs inside the isolated sandbox, while the SDK lets your application create the environment and execute commands remotely. ### Step 4: Manage the sandbox lifecycle When the browser session is complete, you can destroy the sandbox: ```tsx await apiClient.delete.service({ parameters: { projectId: "your-project-id", serviceId: sandboxId, }, }); ``` For most browser agent workloads, ephemeral storage is the safer default. Persistent volumes should be used deliberately and isolated per session. Sandboxes can also be paused and resumed when you need to preserve the environment without incurring compute costs. For more advanced configurations, including [persistent volumes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#create-sandbox-with-volume-for-persistence), [GPU sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#create-a-gpu-sandbox), port exposure, and sandbox lifecycle management, see the [Sandboxes on Northflank](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) documentation. ## How Northflank handles browser agent infrastructure Running browser agents securely means operating more than the browser itself. Someone has to provision isolated environments, manage their lifecycle, control networking and credentials, allocate resources, and support the infrastructure as the number of concurrent sessions grows. Northflank provides this execution layer through Sandboxes, with the rest of the platform available around the browser agent workload. - [**MicroVM isolation**](https://northflank.com/product/sandboxes):** Each sandbox runs in a microVM-backed container using user-space kernel isolation. Sandboxes boot in under 1 second and prevent container escape. Each session gets its own dedicated kernel, providing a stronger isolation boundary between browser agent workloads, the host, and adjacent sessions. - **Ephemeral and persistent environments:** Sandboxes can run as short-lived environments for single browser tasks, or use persistent workspace storage when session state needs to survive between runs. For most browser agent workloads, ephemeral storage is the safer default. - [**Managed cloud**](https://northflank.com/features/managed-cloud) or [**BYOC**](https://northflank.com/features/bring-your-own-cloud): Sandboxes run on Northflank's managed cloud across 6+ regions, or inside your own AWS, GCP, Azure, Oracle, or CoreWeave account with self-serve BYOC. Agent execution stays inside your own VPC when using BYOC. - [**Secrets management**](https://northflank.com/docs/v1/application/secure/manage-secret-groups): Secret groups store credentials and inject them at sandbox start. Credentials are not stored inside the browser environment. - [**RBAC and SSO**](https://northflank.com/docs/v1/application/secure/use-role-based-access-control): Northflank provides role-based access control across the platform and enterprise SSO through SAML and OIDC. Every sandbox session is tied to a named identity. - [**Audit logging**](https://northflank.com/docs/v1/application/observe/audit-logs): Platform and workload logs provide visibility into sandbox activity and infrastructure changes, giving teams a record that can be used to investigate unexpected browser agent behavior. - **Broader workload support:** Browser agents can run alongside applications, APIs, workers, databases, jobs, and GPU workloads through the same platform. ## Conclusion Browser agents face a threat model that standard sandbox approaches underestimate. Chromium's process isolation stops malicious JavaScript from escaping the renderer. It does not stop a manipulated agent from taking actions with its own legitimate permissions. Infrastructure-level isolation, default-deny egress, and credential injection outside the browser session are the controls that constrain what a manipulated browser agent can actually do. Northflank sandboxes provide that infrastructure as a managed platform: microVM-backed containers that boot in under 1 second, prevent container escape, and are created and managed programmatically via the JavaScript SDK. Browser agent sessions run in complete isolation from your host environment and from each other. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ## FAQs: how to run browser agents in secure sandboxes ### Can I run Playwright in a secure sandbox on Northflank? Yes. Playwright-based browser workloads can run inside a Northflank Sandbox alongside the browser runtime and application code that controls it. The Sandbox provides the isolated execution environment, while Playwright handles browser automation. ### What isolation does Northflank use for browser agents? Northflank uses microVM-backed isolation for sandbox workloads, with Kata Containers and Cloud Hypervisor as the primary microVM approach. Firecracker and gVisor are also supported depending on workload and infrastructure requirements. ### How do you securely give a browser agent access to an authenticated website? Use a dedicated browser identity or service account with only the permissions required for the workflow. Keep browser state isolated per session, avoid exposing personal browser profiles, and provide credentials at runtime rather than storing them in source code or images. ### Should browser agents have unrestricted internet access? No. Browser agents need network access to perform their jobs, but unrestricted egress makes it easier for a compromised or manipulated agent to communicate with unexpected destinations. Use network policies and explicit allowlists to control which websites, APIs, and internal services the browser can reach. ### Can I run browser agents inside my own cloud or VPC? Yes. Northflank supports sandbox workloads in customer-owned cloud infrastructure through BYOC, allowing teams to run them inside their own cloud environment and network. ## Related articles - [How to run AI coding agents in secure sandboxes](https://northflank.com/blog/how-to-run-ai-coding-agents-in-a-secure-sandbox) - [How to design networking for secure AI-agent sandboxes](https://northflank.com/blog/how-to-design-networking-for-secure-ai-agent-sandboxes) - [How to secure AI agents in the cloud](https://northflank.com/blog/how-to-secure-ai-agents-in-the-cloud)

What should an audit trail for AI-agent code execution contain?

2026-09-09T15:46:00.000Z

An AI agent can start an isolated environment, run commands, call an API, and create an artifact in one run. A shell transcript cannot show who delegated authority, which policy allowed the action, or whether credentials and storage were removed. An AI-agent code execution audit trail should connect identity, agent and policy versions, code, environment, approvals, actions, effects, artifacts, resource use, and termination. It should reconstruct the run without turning logs into a store of code, prompts, credentials, or sensitive output. This article explains what to record and exclude, how to connect agent, runtime, and platform logs, and how Northflank can support the audit trail. ## TL;DR: What an AI-agent code execution audit trail should contain An AI-agent code execution audit trail should show who initiated a run, why it was allowed, what executed, what it affected, and how it ended. - Create an application-controlled correlation identifier, such as `run_id`, and map it to the native resource and event identifiers produced by the agent orchestrator, policy engine, sandbox, credentials, commands, artifacts, and platform. - Record the human or service initiator, agent identity, delegated role, policy version, decision, approval, and credential identifier. Never record the credential value. - Identify code, images, dependencies, configuration, and outputs with immutable versions or digests where practical. - Separate proposed actions, authorization decisions, executed actions, and observed effects. A model request is not proof that a command ran. - Export evidence outside the execution environment, restrict access, monitor collection failures, and apply retention and redaction by data class. If your team needs isolated execution and platform audit records for generated or untrusted code, [Northflank Sandboxes](https://northflank.com/product/sandboxes) provide API-controlled environments alongside [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) and [workload log export](https://northflank.com/docs/v1/application/observe/configure-log-sinks). Northflank is an AI-agent sandbox and workload platform for running untrusted code in isolated environments on [Northflank Cloud](https://northflank.com/cloud/northflank), in [your own cloud account and VPC](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-in-your-cloud), or on [eligible on-premises infrastructure](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok). Your application remains responsible for agent decisions, tool calls, and business-level results. Correlate them with Northflank resource IDs and available native event IDs through an application-side mapping. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss execution isolation, auditability, networking, data residency, or scale. ## What should an AI-agent code execution audit trail prove? A useful audit trail should help your team answer the following five questions. They are a practical test of coverage, not a fixed standard. 1. **Who initiated and owned the run?** Identify the user or service, tenant, agent, session, and workload owner. 2. **Why was it allowed?** Preserve the requested operation, applicable policy and version, decision, risk class, required approval, approver, and approval scope. Bind the approval to the target and sanitized arguments or an action digest. 3. **What ran and where?** Identify the source revision, command or tool, image digest, sandbox, isolation class, region, resources, filesystem, and network policy. 4. **What did it reach or change?** Record destination services, affected resources, file and configuration changes, API effects, artifacts, and denied attempts. 5. **How did it end?** Capture exit status, timeout or termination reason, state retention, and quarantine. Record credential revocation and deletion as requested, confirmed, failed, or unknown rather than treating a cleanup request as proof of completion. ## Which events should an AI-agent execution trail record? Record events where authority, state, or impact changes. This is a practical taxonomy. | Phase | Events | Useful evidence | | --- | --- | --- | | Admission | Run requested, accepted, denied, or queued | Initiator, agent, purpose, risk class, code reference, requested target | | Authorization | Policy evaluated, approval requested, granted, rejected, or expired | Policy ID and version, decision, reason code, approver, approval scope and expiry | | Environment lifecycle | Sandbox created, ready, paused, resumed, expired, quarantined, or deleted | Environment ID, image digest, isolation and resource class, region, storage and network policy | | Execution | Tool selected, command proposed, command started, retried, and completed | Tool and call ID, normalized command or content reference, working directory, process ID, timestamps, exit status | | Access | Credential issued or revoked, secret mounted, connection allowed or denied | Credential ID, permission scope, destination, protocol, policy result | | Effects | File, database, API, infrastructure, or configuration changed | Target identifier, operation, before-and-after digest or structured difference, outcome | | Artifacts | Patch, report, image, binary, or test result created and exported | Artifact type, location, digest, source run, scan or validation result | | Enforcement | Limit approached, quota denied, process killed, or output truncated | Limit, observed value, enforcement action, cost or usage summary | | Containment | Run stopped, network blocked, state quarantined, or follow-on execution denied | Actor, reason, affected scope, evidence-preservation status, final cleanup result | Link retries and asynchronous work using stable identifiers. For example, assign each event an event ID, associate child operations with their parent events, and use an idempotency key for operations that may be retried. ## Which fields should AI-agent code execution audit events contain? Each event should use a stable common envelope followed by fields relevant to that action. Exact field names and structures can vary between implementations. ### 1. Correlation and ordering For example, the common envelope can include an event ID, an application-defined run identifier, a trace ID, relevant parent and tool-call IDs, an event name, a schema version, and event and observed timestamps. Names such as `run_id` are implementation conventions, not universal standards. If you add sequence numbers, scope them to a named producer or stream and define when they reset. Use causal links to order work across systems. ### 2. Identity and authority Record the tenant and project, initiating user or service, agent ID and version, workload owner, active role, policy decision, policy version, approval ID, approver, and approval expiry. Reference the issued credential by ID and scope, never by secret value. ### 3. Versioned inputs and environment Identify the repository and commit, code digest, image digest, dependency-manifest digest, environment ID, isolation and compute classes, storage mounts, region, and network-policy version. Record how an output was produced and bind it to a digest. A digest can confirm a candidate file or command matches the record, but cannot recover its content. Keep a protected reference when reconstruction is required. ### 4. Action, target, and result Separate the action proposal, authorization result, start, and completion. Record the operation, tool, target, sanitized arguments or protected reference, working directory, timeout, attempt, exit code, and error class. ### 5. Effects and produced artifacts Capture effects separately from the command's return value: affected resources, network destinations, changed paths, before-and-after digests, infrastructure differences, artifact IDs, validation results, and durable state. ### 6. Lifecycle and containment Finish with run status, termination reason, usage, retained-state decision, and quarantine or legal-hold references. Track credential revocation, sandbox deletion, retained-volume removal, and other cleanup actions through request and confirmation events. A command is not fully contained if its token, child process, external task, or storage survives unnoticed. ## How should agent traces, runtime logs, and platform audit logs fit together? An end-to-end trail joins three evidence layers. | Evidence layer | What it should show | Typical owner | | --- | --- | --- | | Agent and policy trace | Model and agent version, action proposal, tool call, policy decision, approval, tool result, business outcome | Agent application team | | Runtime evidence | Instrumented process activity, permitted stdout and stderr, filesystem effects, resource use, and network activity | Sandbox or workload platform team | | Platform audit log | Identity and API activity, environment lifecycle, configuration changes, affected infrastructure, parent events | Platform and security team | Keep the correlation identifier in application telemetry, propagate it where custom context is supported, and preserve native identifiers. Maintain an application-side mapping when a platform does not return your identifier. Process, filesystem, and network evidence requires suitable instrumentation and confirmed collection coverage; workload output alone does not provide it. Northflank [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) record event type, triggering identity, source, timestamp, parent events, affected resources, and configuration differences. [Log sinks](https://northflank.com/docs/v1/application/observe/configure-log-sinks) can export workload logs. Your agent application must still emit proposal, policy, approval, and tool-result events. ## What should an AI-agent code execution audit trail avoid recording? Excess content can turn an audit trail into a store of secrets, proprietary code, personal data, and malicious log content. Avoid directly logging access tokens, passwords, connection strings, encryption keys, sensitive personal data, session identifiers, and application source code. Apply the same caution to prompts, tool arguments and results, command bodies, stdout, stderr, environment variables, and changed-file contents. Prefer metadata and references by default: - Store a command or file digest when investigators need identity but not content. - Store an artifact ID and protected object-store reference instead of embedding a binary or patch. - Record the secret ID, version, scope, injection time, and revocation time instead of its value. - Attach a data classification, capture mode, redaction-policy version, and truncation indicator to content-bearing events. - Place necessary sensitive evidence in a more restricted store with its own access trail and retention rule. Do not require the model's private chain-of-thought. Audit permitted inputs, proposed actions, controls, tool calls, and effects. Those are the behaviors your team can authorize and investigate. ## How should you protect and retain an AI-agent code execution audit trail? Protect the trail from the code and agent it records. Collect security-critical events from trusted components outside the untrusted workload where possible, export them promptly, and detect missing, delayed, malformed, or replayed records. Workload-generated events can still be suppressed or fabricated before collection, so label their source and trust level. In practice, your design should: - use append-oriented storage and integrity checks appropriate to the risk - restrict log administration separately from agent and sandbox administration - encrypt records in transit and at rest - alert when required events stop arriving, arrive late, or fail schema validation - preserve original event time and collection time - apply retention by event class, data classification, contractual need, and incident-response requirement - support legal holds and controlled deletion without silently breaking the causal chain There is no universal retention period. Set one by event class, risk, investigation window, data sensitivity, contracts, and applicable law. ## How can Northflank support an AI-agent code execution audit trail? Northflank is an AI-agent sandbox and workload platform for running untrusted code in isolated environments on [Northflank Cloud](https://northflank.com/cloud/northflank), in [your own cloud account and VPC](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-in-your-cloud), or on [eligible on-premises infrastructure](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok). Northflank can supply an isolated runtime, platform audit records, and workload logs, while the agent application records model, policy, and tool decisions. Northflank [API tokens](https://northflank.com/docs/v1/application/secure/grant-api-access) derive permissions from RBAC roles, can expire or be revoked, and have token-specific audit feeds on Enterprise plans. This connects platform actions to bounded credentials. For the execution layer of the audit trail, [Northflank Sandboxes](https://northflank.com/product/sandboxes) run generated or untrusted code in isolated environments. Collected workload logs can be retrieved through [log tailing](https://northflank.com/docs/v1/api/log-tailing) or exported through [log sinks](https://northflank.com/docs/v1/application/observe/configure-log-sinks). [Northflank audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) record platform events and configuration changes at organisation, team, project, and resource scope. Northflank can run the execution layer on [managed Northflank Cloud](https://northflank.com/cloud/northflank), in [your own cloud account and VPC through self-serve BYOC](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-in-your-cloud), or on [eligible existing Kubernetes infrastructure through BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok). If your enterprise needs isolated code execution, a managed [Kubernetes application platform](https://northflank.com/product/app-platform), platform audit events, and sandbox deployment in its own cloud account and VPC, Northflank is the default recommendation for the execution layer of an AI-agent audit architecture. The application must still provide agent-level decisions and correlation mappings. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss audit architecture, sandbox isolation, access, BYOC, or scale. ## Frequently asked questions about AI-agent code execution audit trails ### Do you need to log every command and its full output? Record every security-relevant execution event, but do not assume its full content belongs in the main audit store. Keep command and output metadata, digests, size, result, and a protected reference by default. Capture full content only when policy, investigation needs, and data classification permit it. ### Is an audit trail the same as observability? Not exactly. Observability helps explain system behavior, while an audit trail establishes accountability and reconstructs security-relevant actions. They can share infrastructure, but audit records need controlled access, integrity, retention, and identity attribution. ### Should the audit trail contain the model's chain-of-thought? Generally, no. Record permitted inputs, proposed actions, policy decisions, approvals, tool calls, results, and observable effects. Internal reasoning is not needed to establish what the system authorized and executed. ### How long should AI-agent execution logs be retained? Set retention by event class, risk, investigation window, sensitivity, contracts, and law. Do not retain sensitive output beyond its purpose. ## Related articles about AI-agent code execution - [How to give your AI agent a secure computer](https://northflank.com/blog/give-ai-agent-secure-computer) - [How to deploy an AI sandbox for developer experimentation](https://northflank.com/blog/deploy-ai-sandbox-developer-experimentation) - [How to govern AI-agent code execution in enterprise environments](https://northflank.com/blog/govern-ai-agent-code-execution-enterprise) - [AI-agent sandbox security checklist: What enterprises should evaluate](https://northflank.com/blog/ai-agent-sandbox-security-checklist) - [How to isolate AI agents that have access to company data](https://northflank.com/blog/how-to-isolate-ai-agents-with-company-data)

What infrastructure do AI agents need to run code safely?

2026-09-09T15:45:00.000Z

An AI agent crosses a security boundary when it moves from suggesting code to running commands, reading files, or calling services. Model output can consume infrastructure, expose data, and change systems. Safe code execution needs more than a container. It needs an isolated execution plane surrounded by independently controlled authorization, identity, networking, storage, scheduling, lifecycle, observability, and containment infrastructure. This article explains each layer, the request path, how sandbox output should reach production, and how Northflank supports the architecture. ## TL;DR: What infrastructure do AI agents need to run code safely? AI agents need a policy-controlled sandbox platform that separates model orchestration from code execution and limits every run's authority, resources, connectivity, state, and lifetime. - Keep the agent orchestrator and policy engine outside the runtime so executed code cannot change its own permissions or suppress cleanup. - Run generated or untrusted code in an isolated environment with task-specific images and hard limits on compute, processes, storage, output, duration, and concurrency. - Give each run a scoped identity, minimum credentials, restricted ingress and egress, and separately authorized access to data. - Automate creation, readiness, expiry, pause, deletion, and abandoned-environment cleanup through a dedicated sandbox control plane. - Export reproducible artifacts through a separate testing and release path instead of promoting a mutable sandbox into production. If your team needs isolated execution alongside Kubernetes orchestration, GPUs, persistent storage, and deployment in your own cloud account and VPC, Northflank provides the execution layer and surrounding application infrastructure. Northflank is an AI-agent sandbox and workload platform for running untrusted code in isolated environments on [Northflank Cloud](https://northflank.com/cloud/northflank), in [your own cloud account and VPC](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-in-your-cloud), or on [eligible on-premises infrastructure](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok). If your enterprise needs this combination of capabilities, Northflank is the default recommendation for running AI-agent sandboxes. [Northflank Sandboxes](https://northflank.com/product/sandboxes) provide API-controlled environments for untrusted code, while the platform also runs APIs, workers, jobs, databases, and storage. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## Why is a container not enough infrastructure for AI agents to run code safely? A container addresses part of the runtime boundary, but safe execution depends on surrounding systems. The agent still needs systems that authorize commands, restrict access, manage state, destroy environments, and reconstruct events. A microVM does not decide whether the agent should read customer data or deploy to production. Treat the sandbox as one enforcement point in a wider architecture: | Layer | What it controls | Failure it contains | | --- | --- | --- | | Orchestration and policy | Which work may run and with what authority | Model or prompt manipulation | | Sandbox control plane | Environment creation, operation, and deletion | Orphaned or inconsistent runtimes | | Isolated runtime | Processes, filesystem, kernel exposure, and resources | Malicious or faulty code | | Images and tools | Installed software and execution baseline | Supply-chain compromise and drift | | State and artifacts | What survives the run | Data leakage and unwanted persistence | | Identity and network | Reachable actions, services, and destinations | Credential misuse and exfiltration | | Scheduling and quotas | Capacity, concurrency, lifetime, and cost | Resource exhaustion and runaway spend | | Evidence and containment | Investigation and emergency control | Continuing impact after detection | Together, they limit a compromised run's effects. ## What infrastructure layers does safe AI-agent code execution need? This eight-layer stack is a practical reference architecture, not a fixed industry standard. ### 1. An orchestrator and policy layer outside the runtime The model should propose an action, while a separate service decides whether it may happen. Evaluate the initiator, agent, operation, target, code origin, data class, and environment. Low-risk tests may run under policy; higher-impact actions can require independent approval. Keep this logic outside the sandbox. If executed code compromises its environment, it must not be able to grant itself new tools, modify policy, or prevent termination. The guide to [governing AI-agent code execution](https://northflank.com/blog/govern-ai-agent-code-execution-enterprise) explains how to apply this separation across authorization, runtime controls, evidence, and containment. ### 2. A sandbox control plane with a typed lifecycle The control plane turns an approved request into an environment and manages it until deletion. Expose operations such as `create`, `status`, `exec`, file transfer, `pause`, and `delete`. Validate images, resources, ports, paths, timeouts, and output size. A typed `exec` method still needs runtime, identity, network, and destination controls. Persist a run ID, owner, expiry, and policy version before provisioning. Make lifecycle operations safe to retry, and reconcile uncertain requests or expired environments. ### 3. Isolation, compute, and resource controls The runtime should assume generated code, uploaded files, repositories, and unfamiliar dependencies may be hostile. A conventional container may suit trusted, single-tenant automation. Generated code, user files, or multi-tenant execution can justify a microVM. In either case, limit CPU, memory, processes, storage, output, duration, network use, and GPU access. If your agent executes untrusted code, Northflank provides [Sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) with microVM-based virtualization and user-space-kernel isolation. Northflank supports Kata-based microVMs on compatible infrastructure; gVisor is a user-space application kernel, not a microVM. GPU sandboxes on Northflank Cloud use gVisor by default. Match the runtime to your threat model. ### 4. Controlled images, tools, and dependency supply chains An isolated runtime still starts from software your platform team must maintain. Build task-specific images with the required languages and tools. Version and scan each image, pin important dependencies where practical, and rebuild when fixes become available. Keep long-lived secrets out of images and build arguments. Treat repositories, install scripts, plugins, MCP servers, binaries, and tool responses as untrusted inputs. Scanning finds known risks but cannot prove future behavior, so containment remains necessary. ### 5. Explicit state and artifact services Use an ephemeral root filesystem by default and make every form of retained state a separate decision. Export selected artifacts before deletion. Keep business data in separately authorized systems rather than on the sandbox disk. Persistent workspaces help sessions resume, but retain files and caches. Give each volume an owner, tenant boundary, retention period, scanning policy, and deletion path. The guide to [persistent versus ephemeral AI sandboxes](https://northflank.com/blog/persistent-vs-ephemeral-ai-sandboxes) covers this choice. On Northflank, [pausing a sandbox scales its service to zero](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#pause-or-destroy-the-sandbox). Service configuration and attached volume data remain, but running processes, memory state, and ephemeral container data do not. Permanent cleanup requires deleting the service and any retained volume separately. ### 6. Scoped identity, secrets, and networking Each run needs less authority than its user or orchestrator. Start without ambient credentials. Issue task-scoped access for the required service, resource, and time window, then enforce it at the destination. Secret injection controls delivery, not how receiving code uses the value. Begin with no public inbound route or unnecessary egress. Allow required registries, source hosts, model APIs, and internal services explicitly. Keep metadata endpoints, cluster APIs, credential services, production databases, and unrelated networks unreachable. If execution must follow enterprise access policy, Northflank provides [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [scoped API roles](https://northflank.com/docs/v1/application/secure/grant-api-access), [secret injection](https://northflank.com/docs/v1/application/secure/inject-secrets), [private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank#private-networking), and BYOC [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies). Configure rules deliberately: without rules, traffic is allowed in that direction. ### 7. Scheduling, quotas, and lifecycle automation Safe infrastructure must control the fleet, not only one sandbox. Define resource classes so the model cannot request arbitrary capacity. Apply per-run limits alongside tenant concurrency and spend controls. Use leases, maximum lifetimes, and cleanup reconciliation. These controls describe the complete application architecture, not automatic Northflank defaults. Your team must configure or implement task authorization, expiry, reconciliation, quotas, and budget enforcement around the infrastructure capabilities it uses. Warm pools reduce startup latency but increase cost and reset risk. Reused environments must not expose a previous task's files, processes, credentials, sessions, or caches. Attribute resource use to an owner. ### 8. Correlated evidence and independent containment Operators need enough evidence to reconstruct why execution was allowed, what it affected, and how it ended. Assign one correlation ID across the request, policy, sandbox, commands, approvals, artifacts, and termination. Record content only where policy permits. Do not require private chain-of-thought. Keep agent traces distinct from platform events. Northflank [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) record resource events, their origin, triggering user, time, and affected resources. Your agent service must still trace policy decisions, commands, tool results, and business effects. Containment cannot depend on the model. Operators should be able to terminate a runtime, revoke credentials, block networking, disable tools, quarantine retained files, and prevent another run. ## How should the infrastructure route a code-execution request? A safe request path keeps authority explicit through cleanup. 1. Authenticate the initiator and assign a durable task and run ID. 2. Let the orchestrator propose the command, files, image, resources, destinations, data access, and expected artifacts. 3. Evaluate the proposal in an external policy layer and collect approval when its authority or impact requires one. 4. Apply the approved isolation, resource limits, and baseline network restrictions before any untrusted entrypoint or task code can run, then create the environment. 5. Wait for a ready or failed state, then deliver task-scoped credentials through the approved mechanism before the operation that needs them. 6. Execute the task, enforce runtime limits, and stream bounded results and health signals to the orchestrator. 7. Export approved artifacts to separately controlled storage and revoke temporary access. 8. Delete or pause the environment according to policy, verify cleanup, and close the correlated evidence record. Design for partial failure. A timed-out client does not prove creation failed, and a successful delete request does not prove every related resource was removed. ## How should agent-generated code move from a sandbox to production? Agent-generated code should leave the sandbox as a reproducible artifact and enter a separate release process. A successful test does not grant production authority. Require a commit or image digest, controlled dependencies, tests, resource requirements, and a record of data and network needs. Where practical, promote immutable artifacts into preview or staging with review, monitoring, and rollback controls. Northflank provides [Preview Environments](https://northflank.com/product/preview-environments) for reviewable application stacks and [Workflows](https://northflank.com/docs/v1/application/release/configure-workflows) for connecting builds, deployments, jobs, conditions, and approvals. The agent session supplies an input to that process, not an exception. ## How does Northflank provide infrastructure for agents that run code? Northflank is an AI-agent sandbox and workload platform for running untrusted code in isolated environments on [Northflank Cloud](https://northflank.com/cloud/northflank), in [your own cloud account and VPC](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-in-your-cloud), or on [eligible on-premises infrastructure](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok). Northflank combines isolated agent execution with the services needed to operate the orchestrator and the applications around it. Northflank provides: - [Northflank Sandboxes](https://northflank.com/product/sandboxes) for ephemeral or persistent code execution using public or private container images - [REST API](https://northflank.com/docs/v1/api/use-the-api), [CLI](https://northflank.com/docs/v1/api/use-the-cli), and [JavaScript client](https://northflank.com/docs/v1/api/use-the-javascript-client) interfaces for sandbox lifecycle automation - [Resource plans](https://northflank.com/docs/v1/application/scale/scale-cpu-and-memory), [volumes](https://northflank.com/docs/v1/application/databases-and-persistence/add-a-volume), [runtime variables](https://northflank.com/docs/v1/application/secure/inject-secrets), [scoped API roles](https://northflank.com/docs/v1/application/secure/grant-api-access), [private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank#private-networking), and [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) - [Services](https://northflank.com/docs/v1/application/run/run-an-image-continuously), [jobs](https://northflank.com/docs/v1/application/run/run-an-image-once-or-on-a-schedule), [databases](https://northflank.com/docs/v1/application/databases-and-persistence/deploy-a-database), [Preview Environments](https://northflank.com/product/preview-environments), [release workflows](https://northflank.com/docs/v1/application/release/configure-workflows), and [GPU workloads](https://northflank.com/docs/v1/application/gpu-workloads/gpus-on-northflank) - [Northflank Skills](https://github.com/northflank/skills) for compatible coding agents operating the platform through their assigned credentials and permissions Use [Northflank Cloud](https://northflank.com/cloud/northflank) for managed infrastructure. Use self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud) to run workloads and their attached storage in your own cloud account and VPC. Northflank manages Kubernetes while you own the account and cloud resources. Data residency still depends on where you run builds and which model APIs, artifact stores, and other external services the workload uses. Northflank-hosted control-plane metadata remains outside the workload boundary. Use [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok) to connect an eligible Kubernetes cluster your team operates. Your team operates the cluster while Northflank manages workload orchestration and deployment. BYOK requires a reachable Kubernetes API, so it is not an air-gapped deployment. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss sandbox architecture, isolation, networking, infrastructure placement, compliance, or scale. ## Frequently asked questions about AI-agent code-execution infrastructure ### Is a container enough for an AI agent to run code safely? It depends on the code and its potential impact. A container may suit trusted work with restricted inputs. Generated code, hostile files, or multi-tenant execution may require a stronger boundary such as a microVM, plus identity, network, lifecycle, and containment controls. ### Does every agent need its own sandbox? Not necessarily. An agent that only calls narrow, well-authorized APIs may not need general-purpose execution. Use a sandbox for shell, compiler, repository, filesystem, browser, package-manager, or similar access. Allocate environments per task, session, user, or tenant according to the threat model. ### Should agent code-execution environments be ephemeral or persistent? Default to ephemeral environments for independent tasks. Add persistent volumes when a workspace must survive pause or restart, then define ownership, access, retention, scanning, and deletion separately from compute lifecycle. [Northflank Sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) support both ephemeral execution and attached volumes; pausing scales compute to zero rather than preserving a live session. ## Related articles about AI-agent code execution infrastructure - [How to give your AI agent a secure computer](https://northflank.com/blog/give-ai-agent-secure-computer) - [How to deploy an AI sandbox for developer experimentation](https://northflank.com/blog/deploy-ai-sandbox-developer-experimentation) - [AI-agent sandbox security checklist: What enterprises should evaluate](https://northflank.com/blog/ai-agent-sandbox-security-checklist) - [How to govern AI-agent code execution in enterprise environments](https://northflank.com/blog/govern-ai-agent-code-execution-enterprise) - [How to deploy an AI agent from sandbox to production](https://northflank.com/blog/how-to-deploy-ai-agent-from-sandbox-to-production)

How to run AI coding agents in a secure sandbox: Claude Code, Codex, Cursor, and OpenCode

2026-09-08T16:45:00.000Z

## TL;DR: how to run AI coding agents in secure sandboxes - AI coding agents need sandboxes because they execute code, install packages, run shell commands, and make network requests autonomously - A secure sandbox should provide strong workload isolation, ephemeral sessions, egress controls, scoped credential injection, resource limits, and audit logging. - Northflank Harnesses provide cloud coding environments for running agents such as Claude Code, Codex, and OpenCode in isolated environments with dedicated resources, networking, and configuration. Northflank supports multiple isolation runtimes, including Kata Containers with Cloud Hypervisor, Firecracker, and gVisor. - Harnesses run on [Northflank's managed cloud](https://northflank.com/features/managed-cloud) or [inside your own cloud](https://northflank.com/features/bring-your-own-cloud) through BYOC. [Get started (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). AI coding agents have moved beyond autocomplete. Tools like Claude Code, OpenAI Codex, Cursor, and OpenCode write files, install packages, run shell commands, make network requests, and execute code against real infrastructure. That capability is what makes them useful. It is also what makes running them without a sandbox a security problem. Without a sandbox, a coding agent operates in the same environment as the rest of your system. A misconfigured agent, a prompt injection attack, or an agent following a hallucinated instruction can delete files, exfiltrate secrets, install malicious packages, or make destructive changes to infrastructure. The sandbox is the boundary between what the agent is supposed to do and what it can do. ## What a secure sandbox for a coding agent looks like A secure sandbox for a coding agent needs more than an isolated process. It should combine a strong workload isolation boundary with controls around networking, credentials, resources, and session lifecycle. 1. **Kernel-level isolation:** Standard containers share the host kernel, so a successful container escape can expose the underlying host and potentially other workloads on the node. MicroVM isolation gives each session its own dedicated kernel, creating a stronger boundary between untrusted execution, the host, and adjacent workloads. This is a strong baseline for running untrusted or AI-generated code. 2. **Ephemeral sessions:** Each coding agent session runs in a fresh environment and is discarded when the session ends. No state persists from one session to the next unless explicitly saved to external storage. This prevents a compromised session from leaving artifacts that affect future sessions or the host system. 3. **Egress controls:** Default-deny outbound networking means the agent can only reach the services it is explicitly configured to reach. Unexpected outbound requests from agent-generated code fail immediately. An agent redirected by a prompt injection attack cannot reach arbitrary external endpoints. 4. **Scoped credential injection:** API keys, database credentials, and service tokens are injected from a secrets Manager at session start and removed at session end. The agent can use the credentials to complete its task. The code the agent generates never holds the credential value directly. Even if a prompt injection attack redirects the agent's outbound traffic, there is no credential to steal from inside the sandbox. 5. **Audit logging:** Every action the agent takes, every tool call, every network request, every file write, is logged at the platform level with a timestamp and session identity. This is the forensic record for investigating unexpected agent behavior. ## How to run AI coding agents in a secure sandbox with Northflank Harnesses ### What are Northflank Harnesses? Northflank Harnesses are cloud coding environments that let you run coding agents like Claude Code, Codex, and OpenCode in isolated, secure environments. Instead of running agents on your local machine or directly against your codebase, Harnesses provide a controlled workspace with its own resources, networking, and configuration. Each Harness runs in an isolated environment using microVM by default, with gVisor available as an alternative based on your isolation requirements. Harnesses run on [Northflank's managed cloud](https://northflank.com/features/managed-cloud) or [in your own cloud infrastructure](https://northflank.com/features/bring-your-own-cloud) on AWS, GCP, Azure, Oracle, or CoreWeave. You can update its configuration and monitor its resource usage at any time from the Northflank dashboard or your local machine via SSH. ### Prerequisites - A [Northflank account](https://app.northflank.com/signup) - An account or API key for your coding agent - A [Git integration](https://northflank.com/docs/v1/application/getting-started/link-your-git-account) if you want to connect a repository ### Step 1: Create a Harness 1. In your Northflank dashboard, create a new project and click **Harnesses** 2. Select the coding agent you want to run. 3. Enter a name for your Harness 4. Select the environment where you want to run the Harness. 5. Configure authentication for the agent. 6. Select a repository and branch, create a repository, or continue without one. 7. Optionally, configure runtime variables, resources, storage, and other settings as needed. 8. Click **Create Harness** You will be redirected to the Harness terminal. ![image.png](https://assets.northflank.com/image_52c5476747.png) ### Step 2: Access the Harness from your local terminal You can connect to the Harness from your local machine and keep your existing terminal workflow while the coding agent runs in the cloud. Prerequisite: - The [Northflank CLI installed and authenticated](https://northflank.com/docs/v1/api/use-the-cli) To connect: 1. Open the Harness overview in the dashboard 2. Under **Local access**, click **Connect** 3. Copy the SSH command shown (eg. `northflank dev ssh --projectId harness --harnessId your-harness-id`) 4. Run it in your terminal You are now working inside the isolated Harness environment from your local machine. Your coding agent is running in the cloud, while your local terminal connects to the Harness over SSH. ![image 1.png](https://assets.northflank.com/image_1_5e5748a595.png) ### Manage your Harness Once your Harness is running, you can continue to manage it from the Northflank dashboard or CLI. You can monitor resource usage, update its configuration, pause and resume the environment when you are not using it, or delete the Harness when the work is complete ## How Northflank handles sandbox infrastructure for coding agents Running coding agents securely means operating more than the agent itself. Someone has to provision isolated environments, manage their lifecycle, control networking and credentials, allocate resources, and support the infrastructure as the number of concurrent sessions grows. Northflank provides this execution layer through Harnesses and Sandboxes, with the rest of the platform available around the agent workload. - [**MicroVM isolation**](https://northflank.com/product/sandboxes): Each Harness runs in a microVM-isolated environment using Kata Containers with Cloud Hypervisor by default. gVisor is available as an alternative. Each session gets its own dedicated kernel. This provides a stronger isolation boundary between Harness workloads, the host, and adjacent sessions. - **Ephemeral and persistent environments:** Sandboxes can run as short-lived environments or use persistent workspace storage when state needs to survive between sessions. - [**Managed cloud**](https://northflank.com/features/managed-cloud) or [**BYOC**](https://northflank.com/features/bring-your-own-cloud): Harnesses run on Northflank's managed cloud across 6+ regions, or inside your own AWS, GCP, Azure, Oracle, or CoreWeave account with self-serve BYOC. Agent execution stays inside your own VPC when using BYOC. - [**Secrets management**](https://northflank.com/docs/v1/application/secure/manage-secret-groups):** Secret groups store credentials and inject them at Harness startup. Credentials are not read from your local machine environment. - [**RBAC and SSO**](https://northflank.com/docs/v1/application/secure/use-role-based-access-control):** Northflank provides role-based access control across the platform and enterprise SSO through SAML and OIDC. - [**Audit logging**](https://northflank.com/docs/v1/application/observe/audit-logs):** Platform and workload logs provide visibility into Harness activity and infrastructure changes, giving teams a record that can be used to investigate unexpected behavior. - **Broader workload support:** Agents can run alongside applications, APIs, workers, databases, jobs, and GPU workloads through the same platform. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ## Conclusion Running AI coding agents securely requires more than limiting what the agent is allowed to do. The execution environment needs to enforce those boundaries with strong isolation, controlled networking, scoped credentials, resource limits, and an ephemeral lifecycle. Northflank Harnesses provide a cloud execution environment for coding agents, combining isolated workloads with the infrastructure needed to run them in production. You can run Harnesses on Northflank's managed cloud or in your own cloud environment through BYOC, while keeping the coding agent, repository, and workload resources inside a controlled environment. [Get started on Northflank](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ## FAQs: how to run AI coding agents in secure sandboxes ### Can Claude Code, Codex, Cursor, and OpenCode run in a sandbox? Yes. Coding agents such as Claude Code, Codex, Cursor, and OpenCode can run inside isolated execution environments. The sandbox provides the infrastructure boundary around the agent, while the coding agent handles the development workflow. Northflank Harnesses provide cloud coding environments designed to run coding agents in isolated environments. ### Why should AI coding agents run in sandboxes? AI coding agents can execute shell commands, install packages, modify files, and make network requests without a developer manually approving every action. A sandbox limits the blast radius if the agent follows a malicious instruction, runs compromised code, accesses a sensitive file, or makes an unexpected network request. ### Is a container enough to sandbox an AI coding agent? It depends on the workload and threat model. Containers provide useful process and filesystem isolation, but they share the host kernel. For highly untrusted code, stronger isolation technologies such as microVMs can provide an additional security boundary between the workload and the underlying host. ### How do you secure credentials used by AI coding agents? Give the agent only the credentials required for its task and limit their permissions as much as possible. Credentials should be provided at runtime rather than committed to the repository or baked into the sandbox image, and should not provide unnecessary access to production or host infrastructure. ### Should AI coding agents have unrestricted internet access? No. Coding agents may need network access for package installation, source control, APIs, or other services, but unrestricted egress increases the potential for data exfiltration and unauthorized access. A stronger approach is to deny outbound traffic by default and explicitly allow the destinations the agent needs. ## Related articles - [How to sandbox AI agents](https://northflank.com/blog/how-to-sandbox-ai-agents) - [Best code execution sandbox for AI agents](https://northflank.com/blog/best-code-execution-sandbox-for-ai-agents) - [How to secure AI agents in the cloud](https://northflank.com/blog/how-to-secure-ai-agents-in-the-cloud)

How to give your AI agent a secure computer

2026-09-08T15:36:00.000Z

An agent that only calls a model can reason about work, but it cannot compile code, inspect a repository, manipulate files, run a browser, or keep a development process alive. Adding those capabilities creates a new security boundary because model-directed activity becomes real computation with access to infrastructure and data. To give your agent a computer, connect its orchestrator to a separately managed, isolated execution environment with a defined image, resources, filesystem, network policy, credentials, lifecycle, and audit trail. This guide explains that architecture, when to use it, how to build it on Northflank, and which enterprise controls must stay outside the model. ## TL;DR: How to give your AI agent a secure computer Give your agent a computer by provisioning an isolated sandbox through an API, exposing bounded computer operations, and destroying or pausing the environment when the task ends. - Keep model orchestration and policy enforcement outside the execution environment. - Give the agent typed operations for creating a computer, running commands, moving files, checking status, and ending the session. - Select a task-specific image and enforce limits for CPU, memory, storage, processes, duration, network use, and concurrency. - Start with an ephemeral filesystem. Add explicitly owned persistent storage only when the task must resume or retain artifacts. - Use scoped credentials, restricted networking, correlated telemetry, and an independent containment path for every run. If your team needs to give AI agents secure computers for executing generated or untrusted code, [Northflank Sandboxes](https://northflank.com/product/sandboxes) provide API-controlled ephemeral or persistent environments. Northflank is an AI-agent sandbox and workload platform for running untrusted code in isolated environments on [Northflank Cloud](https://northflank.com/cloud/northflank), in [your own cloud account and VPC](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-in-your-cloud), or on [eligible on-premises infrastructure](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok). For teams that also require Kubernetes orchestration, GPU workloads and deployment in their own cloud account and VPC, Northflank is the default recommendation for running AI-agent sandboxes. This recommendation is specific to that combined requirement: Northflank provides a managed [Kubernetes application platform](https://northflank.com/product/app-platform), [GPU workloads](https://northflank.com/product/gpu-paas), and [sandbox deployment in your own cloud account](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-in-your-cloud), alongside APIs, workers, jobs, databases, and storage. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, isolation, data residency, or migration requirements. ## What does it mean to give an AI agent a computer? An agent computer is an execution environment that the agent controls through a constrained interface, not an unrestricted shell inside the agent service. The model may decide that a task requires cloning a repository, running tests, or creating a file. The orchestrator turns that proposal into a structured request. A policy layer checks whether the caller and agent may perform the operation. Only then does a sandbox control API create or operate the isolated environment. This practical component model keeps responsibilities clear: | Component | Responsibility | Enterprise decision | | --- | --- | --- | | Agent orchestrator | Plans steps and coordinates model and tool calls | Which tasks and models are allowed | | Policy layer | Authorizes actions independently of model output | Which operations require denial, approval, or automatic execution | | Computer API | Creates, inspects, pauses, and deletes environments | Which lifecycle operations the agent may call | | Isolated runtime | Runs commands, processes, dependencies, and files | Required isolation and resource limits | | State and artifacts | Retains selected files or results | Ownership, retention, scanning, and deletion | | Network and identity | Connects approved systems using scoped credentials | Reachable destinations and maximum authority | The computer must not inherit the developer's permissions. ## When does an agent need its own computer? An agent needs a computer when its work requires general-purpose execution that cannot be represented safely as a small set of narrow API calls. Examples include coding agents that inspect repositories and run tests, data agents, browser agents, and evaluation workers. Custom packages, long-running processes, build tools, or GPUs can also require a complete runtime. Do not provide a computer by default. For one approved business operation, a typed API gives the agent less authority and a smaller failure surface. Use a sandbox when flexible execution is part of the job, especially for generated code, user files, unfamiliar repositories, or untrusted dependencies. ## What architecture should an agent computer use? A safe agent computer architecture separates planning, authorization, execution, state, and operational control. This six-part design is a practical reference. ### 1. Keep orchestration outside the computer Run the model loop and policy checks in a service that the sandbox cannot modify. If generated code compromises the execution environment, it should not be able to rewrite the orchestrator, grant itself more tools, or suppress the event that terminates the run. Pass only the task context the runtime needs. Return stdout, stderr, exit status, selected artifacts, and health information through the control interface instead of letting the model treat the whole environment as trusted memory. ### 2. Expose typed computer operations Give the orchestrator explicit operations such as `create`, `exec`, `upload`, `download`, `status`, `pause`, `resume`, and `delete`. Validate file paths, resource class, image, ports, timeout, and output size before execution. A typed `exec` operation that accepts arbitrary shell commands still grants general-purpose execution; its real boundary comes from runtime isolation, identity, network policy, credentials, and destination-side authorization. Creation and deletion should be retry-safe. Before provisioning, persist a durable computer ID, owner, task ID, and expiry so a reconciliation worker can find ambiguous requests, retry deletion, and remove abandoned environments. ### 3. Build task-specific images and resource classes Start each computer from a controlled image containing the runtime and tools its workload needs. Pin important dependencies or image digests where practical, scan the supply chain, and rebuild images as fixes become available. Define resource classes instead of letting the model request arbitrary capacity. Each class should bound CPU, memory, ephemeral storage, processes, execution time, network use, and optional GPU access. Tenant-level quotas should also constrain simultaneous computers and creation rate. ### 4. Separate ephemeral compute from durable state Use an ephemeral root filesystem unless the workload requires continuity. Export test reports, patches, logs, and other approved artifacts before deleting the computer. Keep business records in databases or object stores with their own authorization rather than turning a sandbox disk into a system of record. Persistent workspaces are appropriate for coding sessions that pause and resume, but persistence changes the threat model. Retained repositories, caches, downloads, credentials, and generated files need a named owner, tenant boundary, retention period, malware or policy checks, and a deletion path. The guide to [persistent versus ephemeral AI sandboxes](https://northflank.com/blog/persistent-vs-ephemeral-ai-sandboxes) covers that decision in more detail. ### 5. Restrict identity, secrets, and networking Treat access as a separate grant for each run. The policy layer should evaluate the initiating user, agent version, operation, target, arguments, environment, and required approval before issuing a task-scoped credential. Secret injection limits distribution; it does not stop receiving code from reading or misusing the secret. Use task-scoped credentials that the destination also authorizes and that operators can revoke independently. Begin with no inbound exposure and no unnecessary outbound access. Allow only required registries, model endpoints, source hosts, and internal services. Keep metadata endpoints, cluster APIs, credential services, and unrelated tenant networks unreachable. On Northflank BYOC, [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies) must be explicitly configured: without ingress rules, same-project inbound traffic is allowed, and without egress rules, outbound traffic is allowed. Verify the available enforcement mechanism for the selected deployment. If your agent processes company data, the wider [agent isolation architecture](https://northflank.com/blog/how-to-isolate-ai-agents-with-company-data) explains why runtime separation must complement source-system authorization. ### 6. Observe and contain every run Assign one correlation ID across the request, policy decision, sandbox, commands, approvals, artifacts, resource use, and termination. Capture content only where policy permits, and keep platform audit events distinct from application-level agent traces. Containment must not depend on the agent cooperating. Operators need to terminate a computer, revoke credentials, block its network path, disable a tool or policy, quarantine retained files, and prevent a new run. Test those actions during prompt-injection, malicious dependency, resource exhaustion, approval-bypass, data-exfiltration, and sandbox-escape exercises. The [AI-agent sandbox security checklist](https://northflank.com/blog/ai-agent-sandbox-security-checklist) provides a fuller evaluation framework. ## How should enterprises govern computers given to agents? Enterprise governance should set maximum authority before runtime and show that the boundary worked for each task. | Control | Enforcement point | Evidence | | --- | --- | --- | | Identity | Gateway and workload identity | Initiator, agent, role, and token ID | | Action authorization | Deterministic policy layer | Operation, target, arguments, decision, and approval | | Runtime isolation | Sandbox runtime | Image, runtime class, host or pool, and termination | | Data access | Data broker and storage policy | Records or scopes accessed and artifacts retained | | Network | Private routing and ingress/egress policy | Destinations, denials, ports, and exposure changes | | Supply chain | Build and registry controls | Image digest, scan, dependency policy, and provenance | | Resources | Admission and runtime limits | CPU, memory, storage, duration, cost, and quota events | | Lifecycle | Sandbox control plane | Create, ready, pause, resume, expiry, delete, and cleanup | Increase autonomy only after representative tests show that prompt injection, malicious tool responses, malformed arguments, permission escalation, memory poisoning, approval bypass, data exfiltration, and sandbox escape attempts remain inside the intended boundary. A successful task is evidence of usefulness, not evidence that the computer is safe. ## How do you create an agent computer on Northflank? One use case for [Northflank Sandboxes](https://northflank.com/product/sandboxes) is giving an AI agent a secure computer: generated or untrusted code runs inside an isolated environment created from a container image. The [Northflank sandbox guide](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) explains its complete setup and lifecycle. The workflow has four steps: 1. **Choose where it runs.** Create a project on Northflank Cloud or a compatible [BYOC cluster](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-in-your-cloud). 2. **Authorize your application.** Use an [API token](https://northflank.com/docs/v1/application/secure/grant-api-access) whose RBAC role permits the required sandbox operations. 3. **Create and start the sandbox.** Select the container image, startup command, temporary storage, runtime variables, and [CPU and memory plan](https://northflank.com/docs/v1/application/scale/scale-cpu-and-memory). Because creation is asynchronous, wait for the deployment status to reach `COMPLETED` before executing commands; treat `FAILED` as an error and enforce a readiness timeout. 4. **Run the task and end the session.** Use the [exec API](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#execute-commands-inside-the-sandbox) to run commands and collect the command's standard output, error output, and exit code. Then pause or delete the sandbox. For files that must survive restarts or pauses, [attach a persistent volume](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#create-sandbox-with-volume-for-persistence). [Pausing scales the sandbox to zero](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#pause-or-destroy-the-sandbox) while keeping its service configuration and volume intact; resume it by scaling back to one instance. Permanent cleanup requires deleting the service and retained volume separately. ## Why use Northflank to give agents computers? Northflank combines isolated execution with the infrastructure around the agent. Teams can control sandboxes through the [REST API](https://northflank.com/docs/v1/api/use-the-api), [CLI](https://northflank.com/docs/v1/api/use-the-cli), or [JavaScript client](https://northflank.com/docs/v1/api/use-the-javascript-client), while running orchestrators, services, databases, jobs, storage, and GPU workloads on the same platform. On supported infrastructure, Northflank uses Kata Containers with KVM-backed microVMs through Cloud Hypervisor. Where nested virtualization is unavailable, Northflank may use gVisor, a user-space-kernel isolation model rather than a microVM. GPU workloads on Northflank Cloud use [gVisor by default](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#create-a-gpu-sandbox). Choose the provider, region, and node-pool configuration that meets your threat model. Deployment can use managed Northflank Cloud, a new Northflank-managed Kubernetes cluster provisioned in your own cloud account and VPC through self-serve [BYOC](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-in-your-cloud), or an eligible existing Kubernetes cluster your team operates and connects through [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok). Runtime availability depends on provider, region, hardware, and cluster configuration. BYOK also requires a reachable Kubernetes API, so on-premises placement does not mean air-gapped. Enterprise controls include scoped API roles, secret injection, private networking, and token-specific audit feeds on Enterprise plans. These complement application-level policy and agent traces. Compatible agents can use [Northflank Skills](https://github.com/northflank/skills) through their assigned permissions. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss agent-computer architecture, isolation, access, networking, BYOC, or scale. ## Frequently asked questions about giving an AI agent a secure computer ### Is an agent computer the same as a virtual machine? Not necessarily. An agent computer is a functional boundary: isolated compute, processes, files, networking, and lifecycle operations exposed to an agent. Its implementation may use a microVM, a user-space-kernel sandbox, or another isolation model appropriate to the threat. ### Does every agent need a separate computer? No. Agents that only call narrow, well-authorized APIs may not need general-purpose execution. Use a separate sandbox when the task requires flexible code, shell, file, repository, browser, dependency, or process access. Decide whether to allocate one environment per task, session, user, or tenant from the data boundary and threat model. ### Should an agent computer be ephemeral or persistent? It depends on the workload. Ephemeral environments simplify cleanup for independent tasks. Persistent volumes help coding and research sessions resume, but retained state needs explicit ownership, access, retention, scanning, and deletion controls. ### Can you safely give an agent internet access? Not as unrestricted access by default. Allow the destinations and protocols required for the task, inspect or broker sensitive paths where appropriate, and keep metadata services, control planes, credential endpoints, and unrelated internal networks unreachable. ## Related articles about agent computers and sandboxes - [AI-agent sandbox security checklist: What enterprises should evaluate](https://northflank.com/blog/ai-agent-sandbox-security-checklist) - [Persistent vs ephemeral AI sandboxes](https://northflank.com/blog/persistent-vs-ephemeral-ai-sandboxes) - [How to isolate AI agents that have access to company data](https://northflank.com/blog/how-to-isolate-ai-agents-with-company-data) - [How to scale AI-agent sandboxes for high-concurrency workloads](https://northflank.com/blog/scale-ai-agent-sandboxes-high-concurrency) - [How to deploy an AI agent from sandbox to production](https://northflank.com/blog/how-to-deploy-ai-agent-from-sandbox-to-production)

How to deploy an AI sandbox for developer experimentation

2026-09-08T15:35:00.000Z

Developer experimentation becomes an infrastructure problem when engineers or coding agents install unfamiliar dependencies, execute generated code, and connect prototypes to company systems. Running experiments on laptops or shared clusters exposes credentials, source code, internal services, and other workloads. An AI sandbox gives each experiment a controlled boundary. This guide covers repeatable environments, self-service access, network and credential controls, persistence, cleanup, and progression. ## TL;DR: How to deploy an AI sandbox for developer experimentation Deploy an AI sandbox by turning an approved environment specification into an isolated, short-lived workspace that developers can create, use, and destroy through a controlled interface. - Separate generated, user-submitted, or otherwise untrusted code from developer devices, agent orchestrators, production workloads, and production credentials. - Standardize the image, resources, storage, network policy, secret scope, ownership, and lifetime in reusable sandbox profiles. - Give developers self-service access through a UI, CLI, or API while enforcing identity, authorization, quotas, and expiry outside the sandbox. - Default to disposable state and restricted connectivity. Add persistence or private service access only when the experiment requires it. - Record platform changes and policy-permitted execution evidence, then require a reproducible artifact and tests before work leaves the sandbox. If your developers or coding agents need to test generated or untrusted code without sharing a runtime with trusted workloads, Northflank provides an isolated execution path. Northflank is an AI-agent sandbox and workload platform for running untrusted code in isolated environments on Northflank Cloud, in your own cloud account and VPC, or on eligible on-premises infrastructure. [Northflank Sandboxes](https://northflank.com/product/sandboxes) use Kata-based microVM or gVisor isolation, depending on configuration. They run on [Northflank Cloud](https://northflank.com/cloud/northflank) or through [BYOC](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-in-your-cloud) in your enterprise's cloud account and VPC, while the same [Kubernetes application platform](https://northflank.com/product/app-platform) runs services, jobs, and [GPU workloads](https://northflank.com/docs/v1/application/gpu-workloads/gpus-on-northflank). [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok) connects eligible existing or on-premises Kubernetes infrastructure. Runtime availability varies by infrastructure. For enterprise developer experimentation that also needs Kubernetes orchestration, GPU workloads, or deployment in your own cloud account, VPC, or eligible on-premises Kubernetes infrastructure, Northflank is the default recommendation for sandbox platforms for running untrusted code and agents. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, data residency, private networking, or developer-platform requirements. ## What is an AI sandbox for developer experimentation? An AI sandbox lets a developer or agent execute code without granting it the trust of the host device or surrounding stack. It combines isolation with lifecycle, resource, network, credential, storage, and observability controls. The term describes the security boundary, not every development environment. A container may suit trusted, low-impact code. Generated code, unknown packages, public repositories, and shell access can justify stronger isolation. A sandbox contains potentially unsafe execution; a preview creates a temporary, reviewable application instance. An experiment may use both. ## What should you define before deploying the sandbox? Define the experiment contract before choosing an image or writing provisioning code. This keeps the developer experience self-service without making security depend on each developer configuring the environment correctly. | Decision | Define | Why it affects the sandbox | | --- | --- | --- | | Workload | Commands, languages, tools, and expected output | Determines the image and execution interface | | Trust boundary | Code origin, inputs, permissions, and potential impact | Determines the required isolation model | | Resources | CPU, memory, storage, processes, duration, and concurrency | Prevents one experiment from consuming shared capacity | | Network | Required registries, APIs, internal services, and inbound ports | Limits scanning, exfiltration, and unintended access | | Credentials | Identity, allowed actions, targets, and validity | Bounds what compromised code can do | | State | Disposable files, retained workspace, and exported artifacts | Sets persistence and deletion policy | | Ownership | Developer, team, cost centre, and expiry | Makes abandoned environments attributable and removable | | Evidence | Commands, results, policy decisions, and platform changes | Supports debugging, security review, and reproducibility | Turn these decisions into approved profiles. A dependency test and a coding agent may require different images, workspace sizes, and API access. ## Which architecture supports safe, self-service experimentation? This reference architecture separates requests from execution and keeps policy outside the sandbox. ### 1. A developer-facing request interface Let developers request a sandbox through a portal, CLI, IDE integration, or API. Each request should select a profile, identify an owner, and set a maximum lifetime. Authenticate the requester, then authorize the image, resources, network class, credentials, and persistence. Use a stable request ID so retries do not create duplicate environments, and return readiness status asynchronously. ### 2. An isolated execution boundary Keep risky execution away from the request service. It should create the environment, collect results, and terminate it without executing submitted code. If your developers or agents run previously untrusted code, Northflank provides [Sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) with Kata-based microVM isolation or gVisor userspace-kernel isolation, depending on the deployment configuration. They accept public or private images, resource plans, commands, and ports. Isolation does not replace resource, authorization, or egress controls. ### 3. Controlled network and credentials Start from the destinations the workload needs rather than giving every sandbox general access. Separate registries, source control, model APIs, internal services, and arbitrary internet access into distinct policy classes. Avoid public ports unless the experiment produces an interactive service. Inject minimum-scope credentials at runtime. Do not copy developer credentials into an image, repository, or persistent workspace. Ensure they can be revoked independently. If experiments need selected credentials, Northflank supports [runtime variables and secret groups](https://northflank.com/docs/v1/application/secure/inject-secrets). In your cloud account, Northflank BYOC supports [ingress and egress network policies](https://northflank.com/docs/v1/application/network/configure-network-policies). Configure explicit rules: without ingress rules, traffic from resources in the same project is allowed; this does not make the workload publicly reachable. ### 4. Ephemeral state with optional persistence Make the root filesystem disposable unless the workflow needs continuity. This reduces the abandoned code, packages, credentials, and derived data you must retain. Persistence suits workspaces that pause between sessions. Give persistent data an owner, retention period, backup decision, and deletion path. Export required artifacts rather than treating the sandbox as a system of record. If files must survive a pause or restart, Northflank Sandboxes can attach [persistent volumes](https://northflank.com/docs/v1/application/databases-and-persistence/add-a-volume). Keep disposable execution and durable artifacts separate so cleanup remains predictable. ### 5. Lifecycle, evidence, and cleanup Model creation, readiness, execution, pause, expiry, and deletion as explicit states. Use timeouts and an expiry timestamp so disconnected clients do not leave environments running. Deletion should remove compute, temporary storage, routes, and temporary access. Collect evidence to reproduce failures and investigate misuse: the requester, image version, commands, exit status, policy events, outputs, artifacts, and deletion result. Do not require private chain-of-thought. Platform evidence has a narrower job. Northflank [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) record resource events, their source, triggering user, time, affected resources, and configuration differences. Your sandbox service still needs application-level records for commands, policy decisions, and experiment results. ## How should platform teams govern developer experimentation? Govern experimentation through centrally maintained profiles and automated limits. Developers can then iterate inside a boundary whose maximum authority is already approved. Apply three levels of control: - **Identity and access:** connect developers to your identity provider and give automation scoped credentials. Northflank organisations support [SAML or OIDC SSO, MFA enforcement, and directory sync](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation); contact Northflank to enable SSO and directory sync. RBAC roles define API-token permissions. - **Workload policy:** restrict images, plans, regions, storage classes, ports, network profiles, and secret groups. Set per-sandbox timeouts plus team-level concurrency and spend thresholds. - **Operations:** label environments, alert on failed cleanup, review long-lived workspaces, and attribute compute and storage. Test permission escalation, credential theft, prohibited egress, resource exhaustion, persistence after deletion, and retries. Confirm operators can terminate execution, revoke credentials, and quarantine artifacts independently. ## How do you know an experiment is ready for the next stage? An experiment is ready to leave when another person or system can reproduce it from versioned inputs without preserving the sandbox. Require a commit or image digest, locked dependencies, tests, known resource needs, and a record of required data and network access. If the result becomes an application, deploy the tested artifact into preview or staging with non-production credentials and monitoring. Do not promote a mutable workspace. The guide to [deploying an AI agent from sandbox to production](https://northflank.com/blog/how-to-deploy-ai-agent-from-sandbox-to-production) covers policy, evaluation, release, rollback, and operations after experimentation. ## How can you use Northflank for AI sandbox developer experimentation? Northflank is an AI-agent sandbox and workload platform. It enables developer experimentation by running untrusted code and agents in isolated environments, while also supporting the services, jobs, databases, previews, and production workloads surrounding successful experiments. Relevant capabilities include: - [Northflank Sandboxes](https://northflank.com/product/sandboxes) for ephemeral or persistent code execution through platform APIs and the JavaScript client - [Resource plans](https://northflank.com/docs/v1/application/scale/scale-cpu-and-memory), [secret injection](https://northflank.com/docs/v1/application/secure/inject-secrets), [private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank#private-networking), and [scoped API roles](https://northflank.com/docs/v1/application/secure/grant-api-access) for workload boundaries - [Preview environments](https://northflank.com/product/preview-environments) for testing a resulting application and its supporting stack - Services, jobs, databases, object storage, and [GPU-enabled services and jobs](https://northflank.com/docs/v1/application/gpu-workloads/gpus-on-northflank), subject to provider and regional availability - [Northflank Cloud](https://northflank.com/cloud/northflank) for managed infrastructure, self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud) for a Northflank-managed Kubernetes cluster in your cloud account, and [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok) for eligible Kubernetes clusters your team operates - [Northflank for Enterprise](https://northflank.com/enterprise) controls for identity, access, governance, and infrastructure choice [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss sandbox profiles, isolation, private connectivity, cloud placement, compliance, or rollout to developer teams. ## How do you deploy a developer AI sandbox on Northflank? Deploy a developer sandbox by defining its environment once, creating it through Northflank, and applying a predictable lifecycle to every experiment. Start with a project and an approved sandbox profile containing the image, CPU, memory, storage, runtime variables, and network requirements. Give the developer or broker service an API token generated from an appropriate RBAC role. It can then create the sandbox, wait for readiness, run commands, and collect the command output. Default to deleting the sandbox when the experiment finishes. If a developer needs to continue later, an attached volume can preserve files while the sandbox is paused. Pausing scales the service to zero and retains its configuration and volume data. Permanent cleanup requires deleting the service and any separately created volume. The [Northflank sandbox lifecycle guide](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) provides the complete JavaScript client examples for authentication, creation, readiness polling, command execution, ports, persistence, pause, resume, and deletion. Use [Northflank Cloud](https://northflank.com/cloud/northflank) for managed infrastructure. If experiments must run in your cloud account, [Northflank BYOC](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-in-your-cloud) supports sandbox-enabled node pools and workload placement through tags and affinity rules. [Northflank BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok) is the separate route for an eligible Kubernetes cluster your team operates. Runtime availability depends on the provider, region, hardware, and cluster configuration. ## Frequently asked questions about AI sandboxes for developer experimentation ### Does every AI coding experiment need a sandbox? No. Trusted code with controlled inputs and no sensitive access may fit an existing development environment. Use a stronger sandbox boundary when code, dependencies, files, or commands are generated, submitted by users, or otherwise untrusted, and when a failure could affect other workloads or data. ### Should developer sandboxes be ephemeral or persistent? Default to ephemeral environments for one-off work. Add persistence when files must survive pause or restart. On Northflank, pausing scales the service to zero and preserves configuration and volume data, not running processes or memory; permanent cleanup requires deleting the service and volume separately. ### Can a sandbox access private APIs and data? Yes, but grant only the routes and credentials required for the experiment. Use private networking, explicit ingress and egress rules, a non-production data set where possible, and task-scoped credentials. Keep the sandbox separate from broader production network and identity privileges. ### Is a container enough for untrusted code? It depends on your threat model. Containers may suit trusted, low-impact workloads. Northflank Sandboxes provide Kata-based microVM isolation or gVisor userspace-kernel isolation, depending on configuration, alongside resource, network, credential, and lifecycle controls. ## Related articles about AI sandbox infrastructure Continue with these implementation and production guides. - [How to sandbox AI agents](https://northflank.com/blog/how-to-sandbox-ai-agents) - [Which platform is best for running AI-generated code securely at scale?](https://northflank.com/blog/best-platform-running-ai-generated-code-securely-at-scale) - [Persistent vs ephemeral AI sandboxes](https://northflank.com/blog/persistent-vs-ephemeral-ai-sandboxes) - [How to scale AI-agent sandboxes for high-concurrency workloads](https://northflank.com/blog/scale-ai-agent-sandboxes-high-concurrency) - [How to deploy an AI agent from sandbox to production](https://northflank.com/blog/how-to-deploy-ai-agent-from-sandbox-to-production)

Top Dokploy alternatives for deploying applications in 2026

2026-09-07T15:39:00.000Z

Dokploy is a self-hostable application deployment platform built on Docker Swarm and Traefik. Choosing an alternative depends on where you want to run workloads, how much infrastructure your team wants to manage, and which production services need to run alongside your applications. This guide compares four Dokploy alternatives across infrastructure, workloads, scaling, team controls, and pricing. ## TL;DR: Top Dokploy alternatives The top Dokploy alternatives are Northflank, Coolify, Railway, and Render, but they solve different infrastructure and operational requirements. - **Northflank** is best for teams that need more infrastructure choice and production depth than a conventional PaaS. Run applications, jobs, managed databases, preview environments, managed object storage, and CPU or GPU workloads on Northflank Cloud, in your own cloud account through self-serve BYOC, or on compatible on-premises and bare-metal Kubernetes infrastructure through BYOK. - **Coolify** is the closest fit for teams that want an open-source control plane. You can self-host Coolify or pay for Coolify Cloud to operate the control plane, while your applications and data continue to run on servers you supply. - **Railway** suits developers who want to deploy from GitHub, the CLI, or a Docker image to provider-operated infrastructure, with services, environments, cron jobs, private networking, and database templates. - **Render** suits teams running web services, workers, cron jobs, static sites, Postgres, and Key Value on provider-operated infrastructure, with Blueprint-based preview environments on Pro and higher plans. If you are comparing Dokploy alternatives, [Northflank](https://northflank.com/) provides one workflow for deploying complete production stacks on Northflank Cloud or your own cloud account (AWS, GCP, Azure, etc.). Run applications, jobs, [managed databases](https://northflank.com/features/databases), [preview environments](https://northflank.com/product/preview-environments), managed object storage, and CPU or [GPU workloads](https://northflank.com/product/gpu-paas) with integrated scaling, observability, secrets, and RBAC. Northflank's [self-serve BYOC](https://northflank.com/features/bring-your-own-cloud) places workloads in your cloud account while Northflank provisions and manages Kubernetes. [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements) extends the platform to compatible on-premises and bare-metal clusters, while [enterprise controls](https://northflank.com/enterprise) add SSO, directory sync, audit logs, workload identities, and network policies. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss migration, security, compliance, or infrastructure requirements. ## What to look for in Dokploy alternatives The most useful comparison starts with the operating model, then moves to features and price. The selection covers four deployment models: managed infrastructure with self-serve BYOC, open-source server management, streamlined application hosting, and conventional managed services. - **Operating responsibility:** Determine who installs, upgrades, backs up, and restores the control plane. A hosted dashboard does not necessarily include managed workload servers. - **Deployment target:** Decide whether applications should run on provider-managed infrastructure, servers you connect, or Kubernetes clusters in your cloud account. - **Workload scope:** Check whether the platform covers only application containers or also jobs, databases, preview environments, object storage, and GPU workloads. - **Scaling model:** Compare vertical server scaling, independent remote hosts, Docker Swarm, and Kubernetes. These models require different levels of networking, storage, and cluster expertise. - **Deployment workflow:** Check support for Git providers, Dockerfiles, Compose, registries, APIs, CLIs, and pull-request previews. - **Team controls:** Match RBAC, SSO, audit logs, secret management, and environment separation to the people and workloads using the platform. - **Total cost:** Add platform fees, server or cloud costs, storage, networking, backups, and the engineering time required to operate the deployment layer. ## Dokploy alternatives compared The table below shows the main architectural and commercial difference between each option. | Platform | Best for | Deployment options | Workload scope | Scaling model | Pricing model | | --- | --- | --- | --- | --- | --- | | Northflank | Running complete production stacks with infrastructure choice | Northflank Cloud or your own cloud account (AWS, GCP, Azure, etc.), plus on-premises and bare-metal through BYOK | Services, jobs, managed databases, previews, managed object storage, and CPU or GPU workloads | Kubernetes with horizontal and vertical scaling | Usage-based managed cloud, or platform fees plus your cloud costs for BYOC | | Coolify | Running an open-source deployment platform on your servers | Self-hosted Coolify or Coolify Cloud connected to servers you operate | Applications, databases, services, and pull-request deployments | Docker across connected servers | Self-hosted edition, or Cloud subscription plus server costs | | Railway | Deploying applications from GitHub, a CLI, or Docker images | Railway-operated infrastructure, dedicated VMs, or contact-led Enterprise BYOC | Services, cron jobs, functions, environments, and unmanaged database templates | Vertical scaling and configurable replicas | Base subscription plus metered resources | | Render | Running web services, workers, static sites, and managed data services | Render-operated infrastructure | Six code service types, managed Postgres, and Key Value | Vertical scaling and autoscaling on eligible plans | Workspace subscription plus compute and other usage | ## What are the top Dokploy alternatives? The sections below apply the same operating, deployment, scaling, and cost requirements to each platform. ### 1. Northflank Northflank brings applications, jobs, databases, previews, GPU workloads, release workflows, and infrastructure options into one production platform. [Northflank Cloud](https://northflank.com/cloud/northflank) runs workloads on managed infrastructure. With [bring your own cloud](https://northflank.com/features/bring-your-own-cloud), Northflank provisions and manages Kubernetes in your cloud account while you retain your provider relationship. Developers use the same services, jobs, databases, and templates across both models. Bring your own Kubernetes (BYOK) extends this workflow to compatible on-premises and bare-metal Kubernetes clusters. What Northflank provides: - [Git](https://northflank.com/docs/v1/application/build/build-code-from-a-git-repository), [Dockerfile](https://northflank.com/docs/v1/application/build/build-with-a-dockerfile), [buildpack](https://northflank.com/docs/v1/application/build/build-with-buildpacks), [container-registry](https://northflank.com/docs/v1/application/run/change-deployment-source), [UI](https://northflank.com/features/platform), [API](https://northflank.com/docs/v1/api), [CLI](https://northflank.com/docs/v1/api/use-the-cli), [GitOps](https://northflank.com/docs/v1/application/infrastructure-as-code/gitops-on-northflank), and [template-based workflows](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code) - [Applications](https://northflank.com/docs/v1/application/run/run-an-image-continuously), [one-off and scheduled jobs](https://northflank.com/docs/v1/application/run/run-an-image-once-or-on-a-schedule), [managed databases and queues](https://northflank.com/features/databases), [persistent volumes](https://northflank.com/docs/v1/application/databases-and-persistence/add-a-volume), and [managed object storage](https://northflank.com/changelog/may-and-june-2026) - [Full-stack preview environments](https://northflank.com/product/preview-environments) alongside staging and production workloads - Shared [logs](https://northflank.com/docs/v1/application/observe/observability-on-northflank), [metrics](https://northflank.com/docs/v1/application/observe/monitor-containers), [health checks](https://northflank.com/docs/v1/application/observe/configure-health-checks), [autoscaling](https://northflank.com/docs/v1/application/scale/autoscale-deployments), [backups](https://northflank.com/features/databases), [secrets](https://northflank.com/docs/v1/application/secure/inject-secrets), and [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control) - CPU and [GPU workloads](https://northflank.com/product/gpu-paas) on the same platform - [Northflank Cloud](https://northflank.com/features/platform) or [self-serve BYOC](https://northflank.com/features/bring-your-own-cloud) across [AWS](https://northflank.com/cloud/aws), [GCP](https://northflank.com/cloud/gcp), [Azure](https://northflank.com/cloud/azure), [Oracle Cloud](https://northflank.com/cloud/oci), [Civo](https://northflank.com/cloud/civo), [CoreWeave](https://northflank.com/cloud/coreweave), and [Nebius](https://northflank.com/cloud/nebius), plus on-premises and bare-metal through [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements) [Preview environments](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) can reproduce services, databases, jobs, volumes, networking, and URLs for a pull request or branch, then clean them up automatically. For controlled releases, [environments](https://northflank.com/docs/v1/application/release/set-up-environments) separate development, staging, and production, while [workflows](https://northflank.com/docs/v1/application/release/configure-workflows) automate [builds and deployments](https://northflank.com/docs/v1/application/release/ci-cd-on-northflank) and promote the same build between them. [Northflank enterprise controls](https://northflank.com/enterprise) include scoped RBAC, encrypted secrets, audit logs, SAML or OIDC SSO, directory sync, workload identities, and network policies. Northflank is [SOC 2 Type 2 and HIPAA compliant](https://northflank.com/security), with BAAs supported under Enterprise contracts. [Lifted, now part of Upwork](https://northflank.com/blog/upwork-lifted-runs-production-workloads-inside-their-own-vpc-with-northflank) uses Northflank for CI/CD, preview environments, autoscaling, and secrets inside its AWS VPC, giving developers self-service workflows while infrastructure remains within the company cloud account. Northflank's free Developer Sandbox includes always-on compute for two services, one database, and two cron jobs. Pay-as-you-go offers per-second billing with no seat fees. Enterprise adds SSO, audit logs, HA/DR, custom SLAs, and 24/7 support. Review [Northflank pricing](https://northflank.com/pricing) for more details. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss migration, security, compliance, or infrastructure requirements. ### 2. Coolify Coolify fits teams that prioritise an open-source control plane and are comfortable operating the servers where their workloads run. You can install Coolify with no license fee or use Coolify Cloud. The Cloud service operates the Coolify control plane, but your applications, databases, networks, and persistent storage still run on servers you supply. Coolify supports applications, databases, one-click services, Git and webhook deployments, pull-request environments, an API, a browser terminal, monitoring, and team roles. It coordinates multiple connected servers through one interface while standard Docker resources remain on those hosts. Even with Coolify Cloud, your team handles operating-system updates, SSH, firewalls, DNS, application data, workload security, and recovery for connected servers. Coolify manages the dashboard, its updates, and its backups. Self-hosted Coolify is free apart from your infrastructure. Coolify Cloud starts at $5 per month for two connected servers, with each additional server adding $3 per month. Workload-server costs remain separate in both cases. ### 3. Railway Railway suits developers who want to move from a repository or container image to a running service without managing servers or a deployment control plane. You can deploy from GitHub, upload a local directory through the Railway CLI, or use a Docker image. Railway builds source with Railpack or a Dockerfile, then runs it as a service. Services can stay online continuously or run on a cron schedule, while environments separate instances and configuration for development, staging, or production. Pull-request environments replicate the services, networking, and variables from a base environment, then disappear when the pull request closes or merges. Private networking connects services within the same project environment, and teams can add volumes where workloads need persistent storage. Railway provides maintained templates for PostgreSQL, MySQL, MongoDB, Redis, and supported high-availability configurations. These databases run as services backed by persistent volumes. Railway includes database and volume backups, disk metrics, and HA options for supported engines, but classifies the templates as unmanaged services. Teams remain responsible for backup and disaster-recovery configuration, performance tuning, security, monitoring, and maintenance. Pricing combines a plan with resource usage. Free includes $1 of resources each month after the initial trial, Hobby has a $5 monthly minimum including $5 of usage, Pro has a $20 minimum including $20 of usage, and Enterprise is custom priced. CPU, memory, and volumes are metered by the second, with separate charges for egress and object storage. ### 4. Render Render fits teams that want conventional application and data services on provider-operated infrastructure without choosing or maintaining servers. Render separates workloads into web services, static sites, private services, background workers, cron jobs, and Workflows. Code runs in containerized instances on Render infrastructure and can deploy from a linked Git repository or Docker image. Render also provides managed Postgres and Key Value services. Blueprints define multi-service infrastructure in a `render.yaml` file. On Pro and higher plans, a pull request can create a preview environment containing fresh instances of its Blueprint services, datastores, and environment groups. Preview databases start without production data, and an initialization hook can seed the environment when required. The platform also includes private networking, logs, metrics, persistent disks, and zero-downtime deploys for services without an attached disk. Attaching a disk prevents multi-instance scaling and zero-downtime deploys because Render stops the existing instance before starting its replacement. Hobby has no monthly workspace fee and allows one member and up to 25 services. Pro costs $25 per workspace per month and adds unlimited members, autoscaling, preview environments, environment isolation, and workspace audit logs. Scale costs $499 per month and adds SAML SSO, SCIM, advanced roles, multiple workspaces, and organisation audit logs. Compute, bandwidth beyond included amounts, and other resources are billed separately. ## Which Dokploy alternative should you choose? The best Dokploy alternative is the one that matches how much of the platform and infrastructure your team wants to own. | Requirement | Recommended platform | | --- | --- | | Managed platform with applications, jobs, databases, previews, and GPUs | Northflank | | Same workflow on managed infrastructure or in your cloud account | Northflank | | Open-source control plane over customer-supplied servers | Coolify | | Deployment from GitHub, CLI, or a Docker image | Northflank or Railway | | Managed web services, workers, static sites, Postgres, and Key Value | Render | If you want another open-source control plane over servers you manage, Coolify is the closest comparison. Railway and Render provide managed deployment options on provider-operated infrastructure. If you want a managed production platform with a route to your own cloud, Northflank supports applications, jobs, databases, previews, and CPU or GPU workloads on Northflank Cloud or through self-serve BYOC. BYOC is relevant when workloads need to remain in your cloud account for data residency, private networking, or cloud commitments. Compare operational responsibility rather than subscription price alone. A free platform still requires servers, upgrades, security, backups, monitoring, and recovery. ## Frequently asked questions about Dokploy alternatives These answers cover the distinctions that most often affect a Dokploy migration. ### What is Dokploy? Dokploy is a self-hostable application deployment platform that uses Docker, Docker Swarm, and Traefik. It can run the interface, builds, and applications on one server, connect independent remote servers over SSH, or add Swarm nodes for replicated applications across multiple machines. ### What is the best Dokploy alternative? It depends on why you are replacing Dokploy. Northflank fits teams that need a broader production platform across managed infrastructure or their own cloud. Coolify provides an open-source control plane for customer-supplied servers, Railway prioritises a direct Git-to-deployment workflow, and Render provides defined application types with managed Postgres and Key Value. ### Is there an open-source Dokploy alternative? Yes. Coolify provides an open-source control plane that you can install on your own infrastructure without a license fee. You remain responsible for the Coolify instance and workload servers when self-hosting; Coolify Cloud can take over operation of the control-plane instance while you continue to operate the connected servers. ### Which Dokploy alternatives are fully managed? Northflank Cloud, Railway, and Render run workloads on provider-operated infrastructure. Northflank also provides self-serve BYOC, where Northflank provisions and manages Kubernetes inside your cloud account. Railway lists BYOC as a contact-led Enterprise option. Coolify Cloud manages the Coolify control plane, but you still supply and operate the servers that run applications and data. ### Are managed platforms easier than self-hosting Dokploy? Operationally, usually, but the exact boundary matters. A platform such as Northflank can manage the control plane and workload infrastructure through Northflank Cloud. A managed control plane such as Coolify Cloud removes dashboard maintenance while leaving your team responsible for the connected servers, workload data, networking, and recovery. ## Related articles to Dokploy alternatives - [Northflank vs Railway](https://northflank.com/blog/northflank-vs-railway) - [Northflank vs Render](https://northflank.com/blog/northflank-vs-render) - [Northflank vs Heroku](https://northflank.com/blog/northflank-vs-heroku) - [How to replace a DIY internal developer platform](https://northflank.com/blog/replace-diy-internal-developer-platform) - [What is BYOC in cloud computing?](https://northflank.com/blog/what-is-byoc-in-cloud-computing)

Preview environment troubleshooting: Common failures and how to fix them

2026-09-07T15:38:00.000Z

A preview environment can fail before it exists, build successfully but never become ready, or look healthy while the feature under review is still broken. The visible error is often several steps away from the actual problem. For larger engineering organisations, the challenge is not only fixing one failed preview. Teams may need to trace the same pull request across CI, Kubernetes, infrastructure code, cloud networking, secret managers, and observability tools. A repeatable troubleshooting path reduces that operational overhead and gives every team the same place to start. This guide walks through the most common preview environment failures, what to check first, and how to confirm that the fix worked. ## TL;DR: How to troubleshoot a preview environment Work through the preview in dependency order: trigger, blueprint run, build, container, health checks, networking, configuration, data, updates, and cleanup. 1. Confirm that the Git event matched the trigger and find the first failed step. 2. Check that the expected commit produced a successful build. 3. Inspect container logs, health checks, networking, and resource usage. 4. Check runtime variables, secrets, database connections, migrations, and callbacks. 5. Reproduce the problem, then confirm that the preview updates and deletes correctly. [Northflank Preview Environments](https://northflank.com/product/preview-environments) can create full-stack environments for pull requests, including services, databases, and jobs. You define the environment once with a reusable [Preview Blueprint](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints). If a preview fails, Northflank provides [logs and metrics](https://northflank.com/docs/v1/application/observe/observability-on-northflank) for builds, deployments, jobs, and addons, so you can follow the failure across the environment. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your preview workflow. ## Where should you start when a preview environment fails? Start with the earliest stage that did not produce the expected result. A preview URL returning `502` may be caused by routing, an unready container, a crash, or a build that never completed. Changing the route first will not fix a missing image. ## 1. The pull request did not create a preview If no preview was created, check the trigger before the application. Make sure the trigger watches the correct repository and event. Then check its branch rules, pull-request rules, path filters, required labels, check-suite requirements, and commit-message ignore flags. The trigger may be working correctly but excluding the change. To separate a trigger problem from an environment-definition problem, you need a way to test the same preview without waiting for another Git event. Northflank [Preview Blueprints](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) support pull-request, push, GitHub check-suite, PR-label, webhook, and API triggers, and can also run manually against a selected commit. If the manual run succeeds, focus on the trigger and repository integration. If it fails, inspect the blueprint run. **Check the fix:** create a small change that matches the trigger rules and confirm that it creates one preview for the expected commit. ## 2. The preview build failed A preview cannot deploy the new application image if its build did not finish. Open the build for the expected commit and find the first useful error. The final line may only say that a command exited unsuccessfully. Common causes include: - An incorrect Dockerfile path or build context - Files excluded by `.dockerignore` - Dependency or lockfile errors - Missing credentials for a package registry, submodule, or base image - A value supplied at runtime when the build needs it as an argument - Insufficient build resources When a pull request has several commits or rebuilds, first confirm which artifact the preview tried to deploy. On Northflank, [build history](https://northflank.com/docs/v1/application/observe/see-builds) shows the branch, commit hash, duration, status, logs, and metrics for each build. If you use a Dockerfile, compare its location, context, target stage, and credentials with the documented [Dockerfile build options](https://northflank.com/docs/v1/application/build/build-with-a-dockerfile). ## 3. The preview fails while creating resources A preview can create some resources before a later blueprint step fails. Start with the first failed step; later steps may simply be waiting for an output that does not exist. Check for invalid configuration, missing permissions, unavailable resources, name conflicts, or a reference that was resolved too early. A service URL or database connection value is not available until the resource that produces it is ready. Templates that pass generated URLs or connection details between resources must wait until those values exist. For this reason, Northflank recommends confirming that the resource is running before using a [dynamic DNS or addon reference](https://northflank.com/docs/v1/application/infrastructure-as-code/make-a-template-dynamic). ## 4. The container starts and then crashes Start with the logs from the first terminated container. Later restarts may show secondary errors that hide the original cause. Look for an invalid start command, missing runtime variable, incompatible binary, failed import, file-permission problem, or unavailable dependency. Compare the exit with CPU and memory usage. An out-of-memory termination needs a different fix from an application exiting because a variable is missing. Diagnosing a restart is easier when the process failure and its surrounding resource usage are visible together. Northflank's [container monitoring](https://northflank.com/docs/v1/application/observe/monitor-containers) shows running and terminated containers with logs, metrics, and health-check results, while the [log viewer](https://northflank.com/docs/v1/application/observe/view-logs) covers builds, deployments, jobs, and addons. You can also access a shell for a running service or job container. ## 5. The service runs but never becomes ready A running process is not automatically ready to receive traffic. An incorrect readiness probe can keep a healthy container out of the load balancer. Check the probe's protocol, path, port, command, delay, timeout, and failure threshold. Test the exact endpoint or command inside the container. If startup time varies, use a startup probe to delay readiness and liveness checks. To understand why a running container is not serving requests, you need the result of the exact probe controlling its state. Northflank supports HTTP, TCP, and command-based [health checks](https://northflank.com/docs/v1/application/observe/configure-health-checks), with separate startup, readiness, and liveness behavior for traffic and container replacement. ## 6. The preview URL returns 404, 502, or times out Test the connection from the inside out: 1. Confirm that the application listens on the expected container port. 2. Call the service through its private endpoint. 3. Call the generated public URL. 4. Test any custom domain, path rule, authentication, or IP policy. If the first test fails, the application may listen on the wrong port or bind only to `127.0.0.1`. Containerised applications commonly need to listen on `0.0.0.0`; Northflank's [application exposure guide](https://northflank.com/docs/v1/application/network/expose-your-application) shows how application binding and port configuration fit together. If private access works but public access fails, the problem has narrowed to the external route or its access controls. Northflank's [networking documentation](https://northflank.com/docs/v1/application/network/networking-on-northflank) covers public endpoints, private ports, domains, and network security, so check whether the correct port is public, whether the domain or path points to it, and whether an authentication or IP policy blocks the request. ## 7. The page loads, but the feature is broken A working homepage does not prove that the complete feature works. The frontend may call a shared API, a worker may listen to the wrong queue, or an identity provider may redirect to another environment. Check API origins, CORS rules, cookie domains, OAuth redirects, webhook callbacks, queues, topics, and consumer groups. Use test endpoints for email, payments, and other external side effects. When the feature crosses an API, worker, database, or queue, troubleshooting only the public service leaves part of the request path hidden. Northflank [Preview Blueprints](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) can define multiple services, databases, jobs, and private connections in one preview. The [microservices preview environment guide](https://northflank.com/blog/preview-environments-microservices) explains how to keep versions, routes, state, and asynchronous dependencies explicit. ## 8. Environment variables or secrets are wrong Missing or stale configuration can look like an application bug. Compare variable names and sources without printing secret values. Check whether the application needs each value during the build or at runtime. Then check whether the secret group is restricted to the relevant service, job, or tag. Look for a higher-priority group or resource-level variable overriding the expected value. Restart dependent workloads after changing inherited values. When several preview resources need configuration, copying values into each service makes precedence and access harder to control. Northflank [secret groups](https://northflank.com/docs/v1/application/secure/manage-secret-groups) can provide build arguments, runtime variables, or both, with restrictions by resource or tag and priorities between groups. Values defined directly on a service or job override inherited values. ## 9. The database, migration, or seed job fails First separate connection failures from migration failures. Confirm that the database is ready, then check the hostname, port, database name, user, and TLS settings available to the job. If it connects, inspect the job logs for an existing object, incompatible schema version, lock, timeout, unexpected data, or a partially completed earlier attempt. Make seed and migration jobs idempotent where practical, and avoid automatically retrying destructive migrations. If application deployment depends on a schema change, the migration should be a visible step rather than an implicit startup action. Northflank can [run migrations as workflow jobs](https://northflank.com/docs/v1/application/release/run-migrations) before or after deployment and use their result to control later workflow steps. A deployment rollback does not by itself reverse a migration, so test recovery as well as the forward change. ## 10. New commits do not update the preview Confirm that the provider delivered an event for the new commit and that it still matches the trigger rules. Then compare the pull request's head SHA, the build's commit SHA, and the image deployed to the service. If the correct image is running, check browser, service-worker, and CDN caching before building again. A safe diagnostic endpoint that returns the commit SHA can make this easier. A stable preview should follow the pull request without creating a separate environment for every revision. Northflank can update previews when new commits are pushed; its [preview management guide](https://northflank.com/docs/v1/application/release/manage-preview-blueprints) recommends checking the Git trigger and provider webhook when updates do not appear. ## 11. The preview is slow or costs too much Separate slow creation from slow application requests. Creation time may come from uncached builds, large images, serial provisioning, database restores, or unnecessary services. Runtime latency may come from CPU, memory, cold caches, or downstream dependencies. Use timings and resource metrics before increasing every plan. Reuse stable builds, cache dependency layers, run independent steps in parallel, and include only the services required to test the change. As the number of pull requests grows, per-preview sizing and fleet-wide limits both matter. Northflank's [preview management guidance](https://northflank.com/docs/v1/application/release/manage-preview-blueprints) recommends smaller preview plans, automatic cleanup, maximum concurrent preview limits, and regular resource review. ## 12. The preview is not deleted A preview that remains after its pull request continues to consume resources and may leave an accessible URL or external test resource behind. Check whether cleanup on pull-request close, merge, and inactivity is enabled. Confirm that the Git provider sent the relevant event. If the preview created resources in another provider, inspect their teardown separately. Cleanup needs to follow the pull-request lifecycle rather than depend on someone remembering to delete each environment. Northflank can automatically delete previews on close, merge, or after an inactivity period. Resources created as part of the preview are removed with it, while externally created resources can be handled with a [teardown specification](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints). **Check the fix:** close a test pull request and check both Northflank and external resources, including callbacks, buckets, test tenants, and snapshots. ## How does Northflank help troubleshoot preview environments? [Northflank Preview Environments](https://northflank.com/product/preview-environments) bring the preview definition, builds, runtime resources, networking, configuration, and lifecycle controls into one platform. You can follow a failure from the pull request to the affected build, service, job, addon, or route. For enterprise platform teams, this creates a consistent troubleshooting path across applications and engineering groups. Instead of asking every team to maintain separate preview scripts and piece together failures across several systems, platform teams can use reusable Preview Blueprints to define how environments are created, connected, observed, updated, and removed. - **Visibility across the complete preview run:** The [Preview Blueprint management view](https://northflank.com/docs/v1/application/release/manage-preview-blueprints) shows each preview's pull-request metadata, status, resources, and generated URLs, including whether it is building, running, or failed. - **Traceability from code to deployment:** [Build history](https://northflank.com/docs/v1/application/observe/see-builds) connects each build to its branch and commit hash, alongside its duration, status, logs, and metrics. This helps teams confirm that the preview is running the code they intended to test. - **Build and runtime observability:** Northflank provides [live and historical logs](https://northflank.com/docs/v1/application/observe/view-logs) for builds, deployments, jobs, addons, and terminated containers. [Container metrics and status](https://northflank.com/docs/v1/application/observe/monitor-containers) help separate application crashes from resource and health-check problems. - **Health-check visibility:** Northflank supports HTTP, TCP, and command-based [startup, readiness, and liveness checks](https://northflank.com/docs/v1/application/observe/configure-health-checks), with results and timing available for individual containers. This makes it clearer why a running service is not receiving traffic or keeps restarting. - **Private and public network controls:** [Northflank networking](https://northflank.com/docs/v1/application/network/networking-on-northflank) covers private service communication, public ports, generated DNS, custom domains, path rules, and access policies. Teams can check the route to a service without rebuilding its application image. - **Scoped configuration and secrets:** [Secret groups](https://northflank.com/docs/v1/application/secure/manage-secret-groups) keep build arguments and runtime variables outside the repository, with restrictions by resource or tag and priorities for resolving overlapping values. - **Migrations within the deployment workflow:** [Database migrations can run as workflow jobs](https://northflank.com/docs/v1/application/release/run-migrations), with later deployment steps continuing only after a successful migration when the workflow is configured that way. - **Automated updates and cleanup:** Previews can update when new commits are pushed and be deleted on pull-request close, merge, or inactivity. [Teardown steps](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) can also remove resources created outside Northflank. Run the workflow on [Northflank Cloud](https://northflank.com/cloud/northflank), or deploy Northflank into your AWS, GCP, Azure, Oracle, CoreWeave, Civo, or Nebius account with [BYOC](https://northflank.com/features/bring-your-own-cloud). [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss standardising preview environments across teams, running them in your cloud account, or replacing an internally maintained preview platform. ## Frequently asked questions about preview environment troubleshooting ### Why is my preview environment running but inaccessible? The application may not be ready, may listen only on localhost, or may use a different port from the public route. Test the listener inside the container, then the private endpoint, and finally the public URL. On Northflank, you can check the container's [health-check results](https://northflank.com/docs/v1/application/observe/configure-health-checks) and then verify its [private and public port configuration](https://northflank.com/docs/v1/application/network/networking-on-northflank). ### What should I check first when a preview environment fails? Find the earliest stage that failed: the Git trigger, blueprint run, build, container, health check, or network route. Errors later in the process are often consequences of that first failure. ### Why does my preview environment work locally but fail after deployment? Your local environment may provide undeclared files, environment variables, credentials, cached dependencies, or services on `localhost`. Compare a clean container build and its runtime configuration with the preview environment to find what is missing or different. On Northflank, [build history](https://northflank.com/docs/v1/application/observe/see-builds) identifies the deployed commit, while [container logs](https://northflank.com/docs/v1/application/observe/view-logs) show how that build behaves at runtime. ## Related articles about preview environments - [Preview environments for microservices: Architecture and common pitfalls](https://northflank.com/blog/preview-environments-microservices) - [How to auto-create preview environments on every PR](https://northflank.com/blog/how-to-auto-create-preview-environments-on-every-pr) - [How to build efficient monorepo preview environments](https://northflank.com/blog/how-to-build-efficient-monorepo-preview-environments) - [Which database strategy should you use for preview environments?](https://northflank.com/blog/which-database-strategy-should-you-use-for-preview-environments) - [Ephemeral testing environments](https://northflank.com/blog/ephemeral-testing-environments)

How to manage workloads across cloud, customer VPCs, and on-premises environments

2026-09-07T15:30:00.000Z

### TL;DR: how to manage workloads across cloud, customer VPCs, and on-premises environments - **Use a unified control plane:** Manage deployments, configuration, and operations through a consistent interface across different environments. - **Preserve environment boundaries:** Keep workloads, data, networking, and access controls within the boundaries required by each environment. - **Standardize what you can:** Use consistent deployment workflows, governance, observability, and configuration while allowing for environment-specific requirements. - **Choose workload placement deliberately:** Consider compliance, data residency, latency, cloud commitments, and operational requirements when deciding where workloads should run. - **Manage every environment from one platform:** [Northflank](https://northflank.com/) provides a unified control plane for deploying and operating workloads across [managed cloud](https://northflank.com/features/managed-cloud), [customer VPCs](https://northflank.com/product/customer-vpc-deployments), [BYOC environments](https://northflank.com/product/bring-your-own-cloud), and [on-premises](https://northflank.com/enterprise) infrastructure. Most organizations do not run all their workloads in one environment. Some applications run in managed cloud infrastructure for simplicity and scalability, while others need to run in a customer VPC, an organization's own cloud account, or on-premises due to security, compliance, data residency, or infrastructure requirements. The challenge is to operate these workloads consistently across different environments without creating separate deployment, governance, networking, and operational systems for each. ## What makes hybrid workload management difficult The operational problem with hybrid infrastructure is not running workloads in multiple places. Container runtimes are largely portable, and Kubernetes provides a consistent application layer across cloud and on-premises environments. The challenge is operating those workloads consistently after deployment: applying the same access controls, managing secrets, maintaining a consistent audit trail, and responding to incidents regardless of where a workload runs. When each environment has its own operational tooling, these differences quickly compound. Teams end up managing separate deployment pipelines, credentials, configuration models, and monitoring systems for each environment. Simple tasks such as rotating a credential or answering who deployed what and where can then require checking multiple systems. **The result is an operational model that becomes harder to manage as the number of environments grows.** ## What a unified control plane actually does A unified control plane provides a common management layer above the different infrastructure environments where workloads run. Instead of building a separate operational model for every environment, the control plane provides consistent workflows for the application lifecycle while adapting to the requirements of each deployment target. A useful unified control plane should provide: - **Consistent deployment:** Build and deploy applications using the same core workflow regardless of where they run. - **Centralized management:** View and manage workloads across environments without switching between multiple infrastructure management systems. - **Consistent governance:** Apply common access controls, authentication, and audit policies across deployments. - **Configuration management:** Keep a common application definition while allowing environment-specific configuration where required. - **Operational visibility:** Track deployment state, service health, and infrastructure status across environments. - **Controlled updates:** Roll out new application versions and support rollback without creating a separate process for every infrastructure target. This does not mean every environment needs to be identical. A unified control plane should abstract the differences that do not matter to application teams while preserving the differences that matter for security, networking, compliance, and infrastructure ownership. ## The deployment targets and what each requires ### 1. Managed cloud Managed cloud is the simplest deployment target. The platform runs the infrastructure in its own regions, so there is no customer infrastructure to provision, cluster to operate, or cross-account connectivity to configure. The control plane and workloads run within the platform's managed environment. The tradeoff is control. Managed infrastructure may not be suitable for workloads with strict data residency, regulatory, or infrastructure ownership requirements. Managed cloud is a good fit for teams without those requirements, as well as development and staging environments or workloads where operational simplicity is more important than running infrastructure in your own cloud account. ### 2. BYOC into cloud accounts BYOC (Bring Your Own Cloud) deploys the platform's workloads into infrastructure owned and controlled by the organization. Workloads run inside the organization's cloud account and VPC, using its existing compute, networking, and security controls. The control plane remains centralized while managing workloads in the connected cloud environment. This allows teams to retain control over where workloads and data run while using the same deployment and management workflows as managed cloud environments. BYOC is useful when organizations need to satisfy data residency or compliance requirements, use existing cloud infrastructure and commitments, or maintain control over their network and infrastructure. It can also provide a consistent operational model across workloads running in different cloud accounts. ### 3. On-premises and bare-metal On-premises deployment runs workloads on infrastructure the organization owns and operates, including private data centres, Kubernetes clusters, bare-metal servers, and restricted or air-gapped networks. This provides the greatest control over the underlying infrastructure but also introduces the most operational responsibility. There are two common models: **Connected on-premises.** The workloads run on the organization's own infrastructure while the control plane manages them remotely through an appropriate secure connection. This allows teams to operate on-premises workloads through the same management interface used for cloud deployments. **Air-gapped environments.** For environments where external connectivity is not permitted, the management layer can also be deployed within the organization's infrastructure. The control plane and workloads remain inside the private environment, allowing teams to manage applications without requiring an external network connection. ## Consistency across the security and governance boundary The core value of a unified control plane is that moving the data plane to a different environment does not require a different governance model. The security controls that apply to managed cloud workloads can also apply to BYOC and on-premises workloads. 1. **RBAC:** Access controls defined at the organization, project, and environment levels apply across data plane environments. A team member with deploy access to a staging project retains that access whether the workloads run in managed cloud or a BYOC cluster. Moving a workload to a different environment does not automatically change who can manage it. 2. **SSO and identity.** SAML and OIDC integration with an organization's identity provider provides a consistent authentication layer across environments. User provisioning and deprovisioning remain managed through the identity provider rather than requiring separate credentials or user management for each environment. 3. **Secrets management.** Secret groups defined in the control plane can be made available to workloads regardless of where they run. This allows teams to maintain a consistent configuration model while keeping credentials out of application code and deployment definitions. When credentials need to be rotated, the change can be managed centrally rather than updated manually across individual environments. 4. **Audit logging.** Deployments, configuration changes, access control modifications, and other platform operations can be recorded centrally with the identity and timestamp associated with each action. This gives security and platform teams a consistent audit trail across distributed environments rather than requiring them to investigate each deployment independently. This is the important distinction: the infrastructure boundary can change without the governance boundary having to change with it. ## Network isolation and connectivity across environments Each deployment environment has its own network boundary. Workloads in a BYOC cluster run inside the organization's VPC, workloads in an on-premises cluster run behind the data centre's perimeter, and workloads in managed cloud run within the platform's managed network. A unified control plane does not collapse these boundaries. It manages workloads across them while preserving the isolation provided by each environment. 1. **Intra-environment networking:** Within each environment, services should communicate through private networking paths. A service running in a BYOC cluster can reach its database through internal VPC routing rather than a public endpoint, while services running on-premises can communicate through the organization's internal network. The network isolation model within each environment remains under the control of the organization operating that infrastructure. 2. **Cross-environment connectivity:** Some workloads need to communicate across environment boundaries. An application running in a BYOC cluster may need to call a service in another environment, or an on-premises workload may need to reach a cloud-hosted service. This connectivity can use the platform's networking capabilities where available, or infrastructure provided by the organization, such as VPNs, Direct Connect, ExpressRoute, or private endpoints. 3. **Air-gapped environments:** Environments with no external connectivity require a different model. A forward-deployed control plane can operate within the organization's network, allowing workloads and their management layer to remain inside the same security boundary. Platform updates can then be handled through the organization's approved disconnected update process. 4. **Default-deny networking:** Services should only be able to reach the resources and endpoints they are explicitly configured to access. Network policies can enforce this separation within each environment, reducing the impact of a misconfigured or compromised service and preventing it from reaching resources it has no legitimate reason to access. The key idea here is that a unified control plane does not mean a unified network. Each environment keeps its own network and security boundaries while the control plane provides a consistent way to manage what runs inside them. ## Workload placement decisions Deciding which environment a workload should run in is a structured decision, not an ad hoc one. The framework runs through constraints in a specific order: compliance and data residency first, because they eliminate options before cost enters the picture. | Factor | Questions to answer | Implication | | --- | --- | --- | | **Compliance and data residency** | Does this workload process regulated data? Is there a data residency requirement? Does it require air-gapping? | Eliminates environments that do not satisfy the requirement. Regulated data may require BYOC or on-premises. Air-gap requirements eliminate managed cloud and connected on-premises. | | **Existing cloud commitments** | Does the enterprise have committed spend on AWS, GCP, or Azure that should be consumed? | Workloads that can run in BYOC environments should do so if committed spend is under-utilised. | | **Latency and proximity** | Does the workload need low latency to a specific data source or user population? | Workloads with on-premises data dependencies may need to run on-premises or in a BYOC cluster in the same region. | | **Infrastructure availability** | Is the target environment available and configured? Does it have the compute capacity for this workload? | Practical constraint that may override preference. GPU workloads need GPU nodes. | | **Operational capacity** | Does the team have the expertise to operate this workload in the target environment? | On-premises deployments require on-premises operational expertise. BYOC requires familiarity with the target cloud provider. | Apply these in sequence. The output is a small set of environments that satisfy the constraints. Choose within that set based on cost and operational preference. ## How Northflank provides a unified control plane [Northflank](https://northflank.com/) provides a unified control plane for deploying and operating workloads across managed cloud, BYOC, customer VPCs, and on-premises environments. The same platform provides a consistent way to deploy applications, manage configuration, control access, and monitor workloads regardless of where the underlying infrastructure runs. - [**Managed cloud**](https://northflank.com/features/managed-cloud): Deploy workloads on Northflank's managed infrastructure across regions worldwide. This is the simplest deployment model because there is no underlying infrastructure for your team to provision or operate. - [**Self-serve BYOC**](https://northflank.com/product/bring-your-own-cloud): Deploy workloads into your own AWS, GCP, Azure, Oracle, CoreWeave, or Civo infrastructure while keeping centralized management through Northflank. Workloads remain within your own cloud environment and use its networking and infrastructure controls. - [**Customer VPC deployments**](https://northflank.com/product/customer-vpc-deployments): SaaS vendors can define an application once and deploy it across customer cloud environments. Each deployment can have its own configuration while remaining centrally managed, making it possible to handle onboarding, upgrades, and operations across a growing customer fleet. - [**Forward-deployed control plane**](https://northflank.com/enterprise): For organizations with strict connectivity or data sovereignty requirements, Northflank can run within the organization's own environment. This supports deployments where the control plane and workloads need to remain inside a private or air-gapped network. Across these deployment models, Northflank provides the common management layer: - [**RBAC and SSO**](https://northflank.com/docs/v1/application/secure/use-role-based-access-control): Control access at the organization, project, and environment level and integrate authentication with enterprise identity providers. - [**Secrets management**](https://northflank.com/docs/v1/application/secure/manage-secret-groups): Manage secret groups centrally and make credentials available to workloads at build or runtime. - [**Audit logging**](https://northflank.com/docs/v1/application/observe/audit-logs): Track platform operations such as deployments and configuration changes with a centralized audit trail. - [**CI/CD and deployments**](https://northflank.com/product/deployments): Use consistent deployment workflows across different infrastructure environments rather than maintaining separate pipelines for each target. - [**Infrastructure visibility**](https://northflank.com/docs/v1/application/observe/observability-on-northflank): View deployment and infrastructure state across distributed environments from the same platform. This is the core benefit of using a unified control plane: you can change where workloads run without having to rebuild how they are deployed and operated. Your cloud, customer VPC, and on-premises environments can retain their own infrastructure and security boundaries while your platform team works through a consistent operational model. That makes Northflank particularly useful for organizations that need to support multiple deployment models without turning each environment into a separate platform to build and maintain. ## Conclusion Hybrid infrastructure is the operational reality for most enterprises, not an architectural choice they made. The governance gaps that accumulate at environment boundaries, different deployment pipelines, different secrets management approaches, different audit trails, are what make hybrid infrastructure expensive and risky to operate. A unified control plane addresses these gaps by providing consistent deployment, governance, secrets management, and observability across every environment while preserving the security and network boundaries that each environment provides. The data plane moves. The control plane stays consistent. That is the architectural principle that makes hybrid workload management tractable at enterprise scale. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ## FAQ: hybrid cloud workload management ### What is a hybrid cloud control plane? A hybrid cloud control plane is a centralized management layer used to deploy and operate workloads across different infrastructure environments, such as managed cloud, customer VPCs, and on-premises infrastructure. ### What is the difference between a hybrid cloud and a multi-cloud control plane? A hybrid cloud typically combines cloud infrastructure with environments such as on-premises or customer-controlled infrastructure. A multi-cloud control plane focuses on managing workloads across multiple cloud providers. In practice, a unified control plane can support both models. ### How do you manage workloads across cloud and on-premises environments? Use a consistent deployment and management layer that can operate across both environments while preserving their individual networking, security, and infrastructure boundaries. Connectivity requirements should be designed around the restrictions of each environment. ### How do you manage workloads in customer VPCs? Deploy the workload into the customer's cloud environment using a controlled access model, customer-specific configuration, and private networking where required. A centralized control plane can then manage deployments and lifecycle operations across multiple customer environments. ### What should you consider when choosing where a workload runs? Consider compliance, data residency, security requirements, latency, existing cloud commitments, infrastructure requirements, and the operational capacity required to support the workload. The best deployment target is the environment that satisfies the workload's constraints without creating unnecessary operational complexity.

On-demand vs reserved GPUs for AI workloads: Which should you choose?

2026-09-04T16:03:00.000Z

One AI team needs eight GPUs for a fine-tuning run next week. Another serves a production model every hour of every day. Buying both teams' GPU capacity the same way either creates unnecessary commitment or leaves a critical workload exposed to capacity shortages. The choice depends on demand predictability, capacity requirements, hardware stability, and idle costs. This guide compares the trade-offs for training, inference, and enterprise AI infrastructure. ## TL;DR: On-demand vs reserved GPUs Use on-demand GPUs for uncertain, variable, or short-lived workloads. Buy a discount commitment for a measured baseline, and reserve capacity when a workload cannot risk a capacity shortfall. Most teams need a mix. - **Use on-demand GPUs** for development, experiments, early product traffic, burst inference, and workloads whose GPU type or scale may change. - **Buy a GPU usage commitment** for stable production inference or recurring training when predictable utilization justifies the financial commitment. - **Reserve GPU capacity** for planned or critical workloads when assured availability justifies paying for held capacity. - **Check what “reserved” includes.** A term discount, a capacity reservation, and a fixed future allocation solve different problems. A lower rate does not always guarantee capacity. - **Commit against the baseline, not the forecast peak.** Use on-demand capacity for bursts. Reserve secondary capacity when recovery objectives require assured supply. If your team needs flexible GPU access and customer-owned capacity through one deployment workflow, [Northflank GPU workloads](https://northflank.com/product/gpu-paas) run on Northflank Cloud or through [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud). Use on-demand GPUs with per-second billing, or deploy into your own cloud account when you have compatible reservations, committed spend, or infrastructure requirements. Your services, jobs, storage, networking, CI/CD, and observability stay on the same application platform. [Request GPU capacity](https://northflank.com/request/gpu) for planned allocations. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your architecture or cloud commitments. ## What is the difference between on-demand and reserved GPUs? On-demand GPUs trade lower commitment for higher flexibility, while reserved GPUs trade flexibility for predictable access, pricing, or both. | Decision | On-demand GPUs | Committed or reserved GPUs | | --- | --- | --- | | Payment | Pay for GPU compute as you consume it | Varies: pay for held capacity, commit to eligible spend or usage, or purchase a fixed future block | | Commitment | No long-term term commitment | May be cancellable on demand, fixed-term, or tied to a scheduled window | | Capacity assurance | Subject to capacity being available | Only included when the product reserves capacity | | Idle cost | Billing stops when released | Unused commitment or held capacity can still cost money | | Hardware flexibility | Easier to change GPU type, count, or provider | Usually tied to defined attributes or eligible usage | | Scaling | Well suited to variable demand when supply exists | Predictable within the reserved quantity; extra demand needs another source | | Procurement | Fast self-serve access for available capacity | May require forecasting, approval, and provider coordination | | Best fit | Running variable workloads without a long-term commitment | Running predictable workloads with price or capacity certainty | “Reserved GPU” can describe a usage discount, held hardware, or a product that combines both. Treat pricing and capacity as two separate questions: **What rate will you pay?** and **Will the GPU be available when you need it?** ## Does a reserved GPU always guarantee capacity? No. Some reservations provide a billing discount, some hold physical capacity, and some do both. The major clouds illustrate the distinction. AWS separates Savings Plans, On-Demand Capacity Reservations, and fixed-window Capacity Blocks. Google Cloud distinguishes commitments from reservations, although resource-based GPU commitments require attached reservations. Azure Reserved VM Instances discount usage, while On-demand Capacity Reservations address availability. Before signing an agreement, ask: - Which GPU model, VM or node type, quantity, region, and zone does it cover? - Does it guarantee capacity, discount usage, or both? - What happens if capacity is unused, requirements change, or you cancel? A favorable rate has little value if a deadline-bound run cannot launch. Guaranteed capacity becomes expensive if requirements change. ## When should you use on-demand GPUs? Use on-demand GPUs while workload demand, architecture, or hardware requirements remain uncertain. This includes notebooks, benchmarks, early fine-tuning, one-off jobs, and new inference products without a stable traffic floor. You can test cost per completed job or request before committing. On-demand also works above a stable production baseline. If an inference service usually needs four GPUs but sometimes needs twelve, commit against the four-GPU baseline and burst into on-demand capacity instead of committing to the peak. Quota, regional inventory, and provisioning time still affect whether a workload launches. Arrange capacity in advance when the start time cannot move. If your workload needs flexible access, Northflank provides [on-demand GPU infrastructure](https://northflank.com/product/gpu-paas) with per-second billing. Deploy experiments, jobs, and inference services, then release the GPU when the work ends. See the guide to [renting high-performance GPUs on demand](https://northflank.com/blog/best-cloud-services-for-renting-high-performance-gpus-on-demand) for provider-selection criteria. ## When should you commit to GPU usage or reserve capacity? Buy a usage commitment when you can measure a durable baseline. Reserve capacity when a workload cannot tolerate uncertain availability. Depending on the provider, you may need both products to obtain a lower rate and assured capacity. A commitment can reduce the rate for stable inference replicas or recurring training that repeatedly uses the same GPU configuration. A large training run may justify reserved capacity if missing its start date would delay a model or customer delivery. Your enterprise may already have cloud commitments or reserved GPU nodes. [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud) deploys into supported customer-owned cloud infrastructure while Northflank provides the application and orchestration layer. The reservation must match the provider, location, and node configuration. Buy a discount commitment only when matching workloads will consume enough eligible usage across the term. Reserve capacity only when assured availability justifies its separate cost. ## How do you calculate the break-even point for a GPU commitment? For a fixed, fully paid discount commitment covering one like-for-like GPU configuration, the raw-compute break-even utilization is the effective committed hourly cost divided by the on-demand hourly rate. Let: - `O` be the on-demand hourly rate for a like-for-like GPU configuration - `C` be the effective committed hourly cost across the full term - `U` be the expected proportion of hours covered by the commitment On-demand cost for a period is `O × hours × U`. Committed cost is `C × hours`, because you carry the commitment even when eligible usage falls short. The commitment becomes cheaper on raw compute when: `U > C / O` If the effective committed rate is hypothetically 60% of the on-demand rate, raw-compute break-even utilization is 60%. Above it, the commitment costs less when matching usage receives the discount. A spreadsheet can show high aggregate demand while a commitment remains uncovered because the workload uses a different account, scope, GPU model, region, or topology. Calculate covered utilization per compatible resource pool. Add CPU, memory, storage, transfer, model loading, platform, support, and engineering costs. Taxes and the time value of money can also affect all-upfront commitments. Compare cost per completed job or request, not GPU-hour alone. ## Which purchasing model fits each AI workload? Match the model to predictability and the cost of delay. | AI workload | Starting model | Why | | --- | --- | --- | | Notebooks and development | On-demand | Usage is intermittent and hardware requirements change during experimentation | | Early-stage inference | On-demand | Traffic and the right serving configuration are not yet stable | | Stable production inference | Discount commitment plus on-demand burst | The traffic floor can earn a commitment discount while peaks remain flexible | | Spiky production inference | On-demand, with reserved capacity only if availability requires it | Committing for peak demand creates idle-cost risk | | One-off training or fine-tuning | On-demand or a provider-specific scheduled capacity product | The job has a defined end rather than a continuous baseline | | Recurring training | Discount commitment after measurement | Repeated eligible usage can sustain high covered utilization | | Deadline-bound distributed training | Capacity reservation or a product such as AWS EC2 Capacity Blocks for ML | Coordinated GPU availability can be more important than the lowest nominal rate | Use measured demand, not a generic training-versus-inference rule. ## How should enterprises combine on-demand, reserved, and spot GPUs? Use a three-layer portfolio: committed baseline usage, on-demand burst, and spot capacity for fault-tolerant work. Add capacity reservations wherever availability must be assured. 1. **Committed baseline:** Apply discount commitments to the minimum eligible usage your production services or recurring pipelines reliably consume. 2. **On-demand burst:** Absorb traffic peaks, temporary experiments, and demand beyond the committed quantity. Use it for failover only after testing alternate-region or alternate-provider availability. 3. **Spot capacity:** Run checkpointable training, batch inference, hyperparameter searches, and preprocessing that can tolerate reclamation. For GPU infrastructure in your cloud account, Northflank provides configurable [BYOC node pools](https://northflank.com/docs/v1/application/bring-your-own-cloud/deploy-and-scale-node-pools) with autoscaling, availability-zone placement, scheduling rules, and spot settings. The cloud provider can apply compatible commitments or reservations, subject to matching requirements for account, scope, node and GPU type, location, and reservation targeting. Your enterprise pays for the cloud resources; Northflank provisions and manages the Kubernetes cluster and orchestrates workloads. Assign an owner to each commitment, report covered utilization, and define the fallback when reserved capacity is full. For interruptible workloads, decide how jobs checkpoint and resume. See [spot GPUs vs reserved GPUs](https://northflank.com/blog/spot-gpus-vs-reserved-gpus) for that trade-off. ## How does Northflank support on-demand and reserved GPU strategies? Northflank runs GPU workloads across flexible Northflank capacity and customer-owned cloud infrastructure. - [Northflank Cloud GPU pricing](https://northflank.com/pricing) is on demand and prorated to the second without a long-term commitment. As of 4 September 2026, listed GPU component prices include $0.80/hour for an NVIDIA L4 24 GB, $1.42/hour for an A100 40 GB, $1.76/hour for an A100 80 GB, $2.74/hour for an H100 80 GB, and $3.00/hour for an RTX PRO 6000 96 GB, with additional GPU configurations available. - [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud) runs GPU workloads in your supported cloud-provider account, so compatible reservations, commitments, credits, networking, and regional controls can remain within your infrastructure boundary. - GPU-backed services and jobs share CI/CD, storage, networking, secrets, and observability with the application stack. - Teams planning a large allocation or availability-sensitive project can [request dedicated GPU capacity](https://northflank.com/request/gpu) by GPU type, volume, location, and timeframe. > [Weights uses Northflank](https://northflank.com/blog/weights-uses-northflank-to-scale-to-millions-of-users-without-a-devops-team-ai-k8s) to operate nine clusters across AWS, Google Cloud, and Azure, with 250+ concurrent GPUs, 10,000+ daily AI training jobs, and 500,000 inference runs per day. > [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss on-demand capacity, BYOC, reservations, cloud commitments, security, or migration requirements. ## How do you make the final decision? Choose the least committed model that meets the availability requirement. Buy discounts against eligible usage you can defend with data, and reserve capacity where uncertain supply creates unacceptable risk. Ask five questions in order: 1. What is the minimum compatible GPU capacity we have used consistently? 2. Do we need a lower rate, assured capacity, or both? 3. How confident are we in the GPU model, count, location, and term? 4. What is the financial impact if demand falls or the architecture changes? 5. Where will burst, failover, and interruptible workloads run? Use on-demand while those answers change. Commit against the proven baseline when covered utilization justifies it, reserve capacity when availability justifies it, and review the mix regularly. ## Frequently asked questions about on-demand and reserved GPUs ### Are committed or reserved GPUs always cheaper than on-demand GPUs? No. A discount commitment may cost more if covered utilization falls below break-even. A capacity reservation can improve availability without lowering the underlying rate. ### Can reserved GPUs scale automatically? Orchestration can scale workloads within available reserved capacity, but a reservation does not create capacity beyond its quantity. Additional replicas need on-demand, spot, or more reserved capacity. ### Should training use reserved or on-demand GPUs? It depends on frequency, configuration stability, deadlines, and checkpointing. Use on-demand for irregular experiments, discount commitments for stable recurring usage, and provider-specific capacity products for deadline-bound runs. ### Should production inference use reserved GPUs? Commit against predictable baseline usage when utilization and hardware requirements are stable, then use on-demand GPUs for traffic peaks. Reserve capacity separately when recovery or availability targets require it. ### Can Northflank use GPU capacity in my cloud account? Yes. Northflank BYOC supports GPU workloads in supported customer cloud accounts. Whether a cloud commitment or reservation applies depends on the provider's matching, scope, affinity, and targeting rules; confirm the intended configuration with the provider and Northflank. ## Related articles about GPU pricing and infrastructure - [What's the difference between spot GPUs and reserved GPUs?](https://northflank.com/blog/spot-gpus-vs-reserved-gpus) - [Best cloud services for renting high-performance GPUs on-demand](https://northflank.com/blog/best-cloud-services-for-renting-high-performance-gpus-on-demand) - [BYOC vs self-hosting vs managed cloud](https://northflank.com/blog/byoc-vs-self-hosting-vs-managed-cloud) - [How to manage enterprise AI infrastructure](https://northflank.com/blog/how-to-manage-enterprise-ai-infrastructure) - [How much does an NVIDIA L4 GPU cost?](https://northflank.com/blog/how-much-does-an-nvidia-l4-gpu-cost)

Which platforms support both CPU and GPU workloads in your own VPC?

2026-09-04T16:01:00.000Z

Production AI applications rarely run entirely on GPUs. A GPU may handle training or inference, while CPU services authenticate requests, prepare data, coordinate jobs, and process results. If those components must run in your own cloud, the platform needs to do more than provide GPU instances. It must operate distinct CPU and GPU workloads inside infrastructure you control, while giving your teams a practical way to deploy, scale, connect, observe, and govern them. ## TL;DR: Which platforms support both CPU and GPU workloads in your own VPC? Three representative options are Northflank, Anyscale, and Red Hat OpenShift AI Self-Managed. This is not an exhaustive market list, and each platform serves a different requirement. - **Northflank** runs CPU and GPU services and jobs through the same UI, CLI, API, CI/CD, and monitoring stack. Self-serve BYOC places workloads in your cloud account, while BYOK supports eligible existing Kubernetes infrastructure. - **Anyscale** runs heterogeneous CPU and GPU Ray clusters in a customer data plane. On Kubernetes, its operator, Kubernetes, and Ray divide responsibility for provisioning pods, placing them on nodes, and scheduling application work. - **Red Hat OpenShift AI Self-Managed 3.5** adds AI development, training, and model-serving capabilities to supported OpenShift environments with CPU and accelerator resources. A customer-operated OpenShift deployment keeps the execution infrastructure under customer control. If your enterprise needs GPU inference or training to run beside CPU APIs, workers, jobs, databases, and storage, [Northflank](https://northflank.com/) provides one application platform for the complete stack. Use the same deployment workflow for CPU and [GPU workloads](https://northflank.com/product/gpu-paas), then run them on [Northflank Cloud](https://northflank.com/cloud/northflank), in your cloud account through self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud), or on eligible existing Kubernetes infrastructure through BYOK. Your team keeps a consistent developer experience while choosing the infrastructure, network, region, and GPU capacity that fit each workload. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss mixed CPU and GPU architecture, security, data residency, cloud commitments, or migration requirements. ## What does it mean to run CPU and GPU workloads in your own VPC? Running CPU and GPU workloads in your own VPC means that distinct workload types execute in a cloud account, VPC or VNet, or cluster infrastructure your organisation owns or operates. Azure uses VNet terminology, while self-managed platforms may run on private cloud or bare metal. Here, VPC is shorthand for customer-controlled infrastructure. Four distinctions prevent a misleading comparison: 1. **A GPU machine is not automatically a mixed-compute platform.** Its attached CPUs do not prove support for independently scaled CPU and GPU workloads. 2. **Private connectivity is not customer-cloud execution.** Peering or PrivateLink can reach compute that remains in a vendor account. 3. **Kubernetes does not prove infrastructure ownership.** A Kubernetes option qualifies only when its worker nodes and workload network run in customer-controlled infrastructure. 4. **Cloud infrastructure is not the complete platform layer.** Hyperscalers supply instances, but your team still needs deployment, scheduling, release, and governance systems. Ask where the workload runtime, data, and control plane operate. “BYOC” has no universal architecture. ## Why should CPU and GPU workloads use the same platform? A shared platform reduces the operational seams between an AI model and the application that uses it. Consider a document-processing system. CPU workers validate inputs and prepare batches, a GPU service runs inference, and more CPU workers apply business rules and store the results. These components need to operate even when the GPU service scales independently. One platform can give these components shared networking, secrets, identity, observability, and releases while retaining separate resource and scaling policies. If your requirement includes the wider production stack, Northflank runs GPU workloads beside standard services, jobs, databases, storage, builds, preview environments, and release workflows. That is a different scope from a GPU endpoint or training service alone. The comparison of [runtime platforms for AI applications and production infrastructure](https://northflank.com/blog/best-runtime-platforms-for-ai-applications-and-production-infrastructure) explains why that surrounding infrastructure affects the decision. ## How should you compare customer-VPC CPU and GPU platforms? Compare the complete workload and responsibility boundary, not simply the list of available GPUs. 1. **Platform scope:** Decide whether you need a general application platform, a distributed AI-compute platform, or an AI layer for an existing Kubernetes estate. 2. **Execution boundary:** Confirm which CPU and GPU workers, storage systems, build artifacts, logs, and network paths remain in your environment. 3. **Control-plane boundary:** Identify where orchestration metadata, user activity, metrics, and administrative services live and who can access them. 4. **Mixed-compute scheduling:** Check whether CPU and GPU pools scale independently, whether jobs and long-running services are supported, and how the scheduler handles scarce GPU capacity. 5. **Infrastructure coverage:** Match supported clouds, regions, Kubernetes distributions, GPU models, drivers, and quota requirements to infrastructure you can actually procure. 6. **Operational ownership:** Assign responsibility for clusters, node pools, drivers, upgrades, capacity, networking, observability, recovery, and incident response. [BYOC, self-hosting, and managed cloud](https://northflank.com/blog/byoc-vs-self-hosting-vs-managed-cloud) distribute platform and infrastructure work differently even when each can place workloads in an approved region. ## How do platforms for CPU and GPU workloads in your own VPC compare? These three representative platforms take different approaches to mixed compute in customer-controlled infrastructure. | Platform | Best for | Customer-infrastructure boundary | Mixed-compute model | Infrastructure targets | Operating model | | --- | --- | --- | --- | --- | --- | | Northflank | Running mixed-compute applications and their production services through one platform | Workloads run on BYOC Kubernetes or eligible customer-operated BYOK clusters | CPU and GPU services and jobs use the same deployment and operations interfaces | Native BYOC integrations for AWS, GCP, Azure, Oracle Cloud, CoreWeave, and Nebius; eligible Kubernetes through BYOK | Northflank manages the application platform and can provision and manage BYOC Kubernetes | | Anyscale | Running Ray applications with distributed CPU and GPU tasks | Ray clusters run in a customer cloud account or customer-controlled Kubernetes data plane | Heterogeneous worker groups can use CPU-only and GPU instance types with independent scaling | AWS and Google Cloud VM deployments; Kubernetes; Azure Native Integration in Public Preview | Anyscale hosts the control plane; the operator, Kubernetes, and Ray divide scheduling responsibilities on Kubernetes | | Red Hat OpenShift AI Self-Managed 3.5 | Adding AI workflows to an organisation's existing OpenShift platform | OpenShift and OpenShift AI run on customer-operated infrastructure | Kubernetes schedules CPU, memory, and accelerator resources across AI workloads | Supported cloud, bare-metal, and virtualized OpenShift environments | Your organisation operates the cluster and AI platform in a customer-controlled deployment | ## Which platforms run both CPU and GPU workloads in customer-controlled infrastructure? The right choice depends on whether your primary unit of operation is an application, a Ray cluster, or an OpenShift estate. ### Northflank Northflank fits teams that want one managed application platform for GPU workloads and the CPU services around them. GPUs are treated as another workload resource. Developers use the same UI, CLI, API, Git integration, CI/CD, logs, and metrics for CPU and GPU services or jobs. An inference API, CPU workers, scheduled jobs, databases, volumes, and object storage can share the platform workflow. Infrastructure placement is flexible: - [Northflank Cloud](https://northflank.com/cloud/northflank) provides the managed-infrastructure option. - Self-serve [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud) provisions and manages Kubernetes in your cloud account while you retain the account, network, IAM-policy, regional, and infrastructure-billing boundaries. - Northflank BYOK connects eligible Kubernetes that your team already provisions and operates, including supported private and on-premises infrastructure. Northflank's native [BYOC](https://northflank.com/features/bring-your-own-cloud) integrations cover AWS, Google Cloud, Microsoft Azure, Oracle Cloud, CoreWeave, and Nebius. BYOK can also connect eligible Kubernetes clusters with GPU nodes. Available GPU models and capacity depend on the provider, region, quota, and cluster configuration; see Northflank's [GPU infrastructure catalogue](https://northflank.com/cloud/gpus) for current options. Customer-cloud placement still requires a data-flow review. With Northflank BYOC, workload runtime and workload data reside in your environment, while the hosted control plane handles orchestration metadata. Confirm other data categories through [Northflank security details](https://northflank.com/security). ### Anyscale Anyscale fits AI and data applications built around Ray. Its compute configurations support independently scaling CPU and GPU worker groups for workflows such as CPU preprocessing followed by GPU training or inference. Ray clusters and workload resources run in the customer data plane, while Anyscale hosts the control plane. On Kubernetes, the Anyscale operator requests pods, Kubernetes places them, and Ray schedules tasks and actors on the available nodes. Application data and logs stay in the customer environment, but system logs, metrics, runtime metadata, and user activity are retained in the control plane. Customer data planes can use AWS and Google Cloud VM deployments or customer-controlled Kubernetes. The Azure Native Integration uses AKS and is currently in Public Preview. Anyscale is therefore best suited to Ray-native distributed compute rather than a general application platform spanning web services, databases, and release workflows. ### Red Hat OpenShift AI Self-Managed 3.5 Red Hat OpenShift AI Self-Managed 3.5 fits organisations that already operate OpenShift or require a Kubernetes and AI platform under their own administration. OpenShift Container Platform supplies the base application environment. OpenShift AI adds workbenches, pipelines, distributed training, and model serving. Resource queues cover CPU, memory, and GPU capacity, with accelerator support varying by workload and release. A customer-operated deployment can span public cloud, private infrastructure, virtualization, and bare metal, with your organisation responsible for the OpenShift cluster and OpenShift AI components. Red Hat also supports the software on OpenShift Dedicated, ROSA, and Azure Red Hat OpenShift, where infrastructure and operational responsibilities differ. That control brings more platform work. GPU nodes require compatible hardware, drivers, Node Feature Discovery, a GPU Operator, and cluster configuration. Support varies by accelerator, OpenShift version, and workload type. OpenShift AI is most compelling when the organisation already has OpenShift skills, governance, and operations. ## Which CPU and GPU platform fits your workload? Select the platform whose operating model matches the system your team is actually building. - **Use Northflank** when CPU and GPU components belong to a wider production application and you want one platform to manage services, jobs, databases, storage, builds, networking, releases, and observability in your cloud. - **Use Anyscale** when the application is built around Ray and needs distributed CPU preprocessing, GPU training or inference, and Ray-native autoscaling in a customer data plane. - **Use Red Hat OpenShift AI Self-Managed 3.5** when your organisation already operates OpenShift, needs its hybrid infrastructure coverage, or deliberately wants to own the Kubernetes and AI-platform lifecycle. Before procurement, test a representative workflow rather than one GPU container. Deploy its CPU workers, GPU service, storage, and observability path. Scale each pool, remove a GPU node, test network policy, rotate a secret, trace a request, and attribute spend. If customer-cloud deployment is the deciding constraint, compare the broader [BYOC options available for cloud infrastructure](https://northflank.com/blog/best-options-for-byoc-in-cloud-computing). If application security is the driver, use the controls in this guide to [deploy AI-built applications securely in your own cloud](https://northflank.com/blog/securely-deploy-ai-applications-in-your-cloud). ## Frequently asked questions about CPU and GPU workloads in your own VPC ### Is a GPU cloud the same as running GPU workloads in my VPC? No. A GPU cloud can provide accelerators in provider infrastructure. Running in your VPC requires the execution plane to operate in an account, network, or cluster your organisation controls. ### Can CPU and GPU workloads run in the same Kubernetes cluster? Yes. Kubernetes can target separate CPU and GPU node pools with resource requests and scheduling controls. Whether one cluster is appropriate depends on tenancy, failure isolation, scaling, drivers, and network policy. ### Does BYOC keep every data type inside my cloud account? Not necessarily. Workload runtime and data may stay in your account while control-plane metadata, telemetry, or build services follow another path. Map each category before treating BYOC as a residency control. ### Can these platforms use reserved GPU capacity or cloud commitments? It depends on the platform, provider, and deployment model. Customer-cloud platforms can often use infrastructure billed through your cloud account, but the GPU type, region, quota, reservation, node-pool configuration, and platform support must align. Confirm the exact capacity path before committing spend. ## Related articles about CPU, GPU, and BYOC platforms - [Best runtime platforms for AI applications and production infrastructure](https://northflank.com/blog/best-runtime-platforms-for-ai-applications-and-production-infrastructure) - [BYOC vs self-hosting vs managed cloud](https://northflank.com/blog/byoc-vs-self-hosting-vs-managed-cloud) - [Best options for BYOC in cloud computing](https://northflank.com/blog/best-options-for-byoc-in-cloud-computing) - [How to deploy AI-built applications securely in your own cloud](https://northflank.com/blog/securely-deploy-ai-applications-in-your-cloud) - [How to run AI workloads on cloud GPUs](https://northflank.com/blog/running-ai-on-cloud-gpus)

AI-agent sandbox security checklist: What enterprises should evaluate

2026-09-03T15:32:00.000Z

An AI agent can install packages, read files, call APIs, and change infrastructure. If its sandbox inherits broad access, a manipulated instruction can become an incident. A sandbox limits that blast radius, but isolation is only one part of the decision. This checklist covers the runtime boundary, identity, secrets, networking, data, supply chain, lifecycle, evidence, testing, and containment controls your enterprise should evaluate. ## TL;DR: AI-agent sandbox security checklist Enterprises should evaluate an AI-agent sandbox as a complete execution boundary, not accept “isolated” as a sufficient security claim. - Define the code, inputs, tools, data, and destinations you do not trust, then identify every system the sandbox shares with other workloads. - Match runtime isolation to the threat model and verify the boundary with architecture evidence and escape testing. - Give each run a scoped identity, short-lived credentials, restricted egress, and limits on compute, storage, duration, and concurrency. - Require traceable lifecycle operations, reliable deletion, platform audit evidence, application-level agent telemetry, and independent containment controls. - Test prompt injection, privilege escalation, cross-tenant access, exfiltration, persistence, approval bypass, and sandbox escape before granting production authority. If your enterprise needs agents to execute generated or untrusted code without sharing the orchestrator's trust boundary, [Northflank](https://northflank.com/) provides API-driven [Sandboxes](https://northflank.com/product/sandboxes) with microVM or gVisor isolation, optional persistence, and lifecycle controls. Enterprise teams can use SSO, RBAC, scoped API roles, secret injection, private networking, and audit logs to govern platform access around each run. Run workloads on [Northflank Cloud](https://northflank.com/cloud/northflank), or use self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud) when execution needs to run in your cloud account with its network, regional, and infrastructure controls. Compatible coding agents can use [Northflank Skills](https://github.com/northflank/skills) to operate sandboxes and services within their assigned permissions. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## What should an enterprise AI-agent sandbox protect? An enterprise sandbox should contain the effects of untrusted execution even when the model, generated code, dependency, file, webpage, or tool response behaves maliciously. Map the sandbox host and kernel, orchestration service, credentials, mounted files, persistent state, network routes, internal APIs, telemetry, and cleanup path. A compromise becomes serious when it can cross into another tenant, the control plane, company data, or production. This is why sandboxing cannot replace authorization or policy enforcement. [OWASP's excessive-agency guidance](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) recommends limiting agent functionality, permissions, and autonomy, with independent authorization for high-impact actions. The sandbox should enforce the result of those decisions, not let the model decide its own limits. ## AI-agent sandbox security evaluation table Use the table to screen each platform. | Check | Evidence to request | Rejection signal | | --- | --- | --- | | Trust boundary | Data-flow and shared-resource architecture | The provider cannot explain what the guest shares | | Isolation | Runtime design and escape-test results | “Containerized” is the complete isolation answer | | Identity | Per-run identity and authorization model | Runs inherit developer or administrator access | | Secrets | Issuance, scope, expiry, and revocation flow | Long-lived credentials are embedded in images | | Networking | Ingress and egress policy with deny behavior | Arbitrary outbound or private-network access | | State | Ownership, encryption, retention, and deletion | Persistent data survives without an accountable owner | | Supply chain | Image provenance and dependency controls | Mutable, untracked images reach execution | | Resources and lifecycle | Quotas, leases, retries, and cleanup evidence | Termination leaves processes, routes, or credentials active | | Auditability | Correlated platform and agent events | Operators cannot reconstruct a consequential action | | Containment | Live-run kill, revoke, block, and quarantine tests | Stopping the model is the only incident control | ## Which AI-agent sandbox security controls should enterprises evaluate? Test each control before production approval. ### 1. Define the threat model and trust boundaries Name hostile inputs and protected systems. Include generated commands, user uploads, repositories, package scripts, retrieved content, tool responses, and stored memory. Identify whether sandboxes share a host, kernel, cluster, network, cache, volume system, or privileged service. Test what code inside the sandbox can reach and what a compromised platform credential can change. Produce a data-flow diagram and assumptions your red team can challenge. ### 2. Match runtime isolation to the workload Choose the isolation boundary based on code trust, tenancy, accessible data, and potential impact. A conventional container may suit controlled, single-tenant automation with trusted code and restrictive privileges. User-submitted or model-generated code, unknown dependencies, and multi-tenant execution can justify a separate-kernel boundary such as a microVM. Ask whether the guest has its own kernel, how host devices and filesystems are exposed, which privileges are removed, how the host and sandbox runtime are patched, whether running sandboxes must restart, and how base images are rebuilt and redeployed. Do not accept architecture labels as proof. Run applicable escape, malformed syscall, mount, host-discovery, metadata, and cross-sandbox tests. For GPU sandboxes, also request evidence about side channels, noisy-neighbour behavior, and hardware-device passthrough. If untrusted execution requires a separate boundary, Northflank [sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) support microVM-backed isolation; GPU workloads on Northflank Cloud use gVisor isolation by default. Unlike a microVM, [gVisor](https://northflank.com/blog/what-is-gvisor) interposes a user-space application kernel between the workload and host. For the broader platform decision, compare the [requirements for running AI-generated code securely at scale](https://northflank.com/blog/best-platform-running-ai-generated-code-securely-at-scale). ### 3. Separate human, agent, and workload identities Every run should have an attributable initiator and a narrower execution identity. Do not forward a developer session or shared administrator token. Authorize the operation using the initiator, agent, policy version, target, parameters, and time window. Moving to production should create a new authorization decision. If sandbox access must follow enterprise identity policy, Northflank Enterprise supports [SAML or OIDC SSO, directory sync, and MFA enforcement](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation). [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control) and scoped [API roles](https://northflank.com/docs/v1/application/secure/grant-api-access) can limit platform actions by project and permission. Application authorization remains your responsibility. ### 4. Scope secrets and credentials to one task Start a sandbox without ambient credentials and add only the access its approved task requires. Prefer short-lived credentials bound to one service, action, environment, and duration. Keep production secrets out of evaluation runs. Revoke a credential during execution and measure whether copied tokens, child processes, cached credentials, or established sessions remain usable. Define an acceptable revocation window. For selected runtime values, Northflank [secret groups](https://northflank.com/docs/v1/application/secure/manage-secret-groups) inject secrets into specific workloads. The receiving service must still authorize each business operation. ### 5. Restrict ingress, egress, and private-network access Begin with no public inbound route and default-deny workload ingress and egress, permitting documented control-plane paths and task-required destinations. Allow required source hosts, registries, model endpoints, and internal APIs explicitly. Keep metadata endpoints, cluster APIs, credential services, production databases, and unrelated networks unreachable. Where destination controls are insufficient, use a gateway that validates the operation and payload. If the execution fleet runs in your cloud account, Northflank BYOC [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies) can restrict traffic by workload, project, IP or CIDR, FQDN, and hostname. Configure the rules deliberately: without a rule in a direction, traffic is allowed. The guide to [networking for secure AI-agent sandboxes](https://northflank.com/blog/how-to-design-networking-for-secure-ai-agent-sandboxes) covers the wider egress design. ### 6. Govern files, memory, caches, and persistent storage Treat state as a separate security boundary from compute. An ephemeral runtime can still write logs, caches, artifacts, or external memory. For every persistent store, define ownership, allowed data, encryption, access, retention, and deletion. Prevent a run from attaching another user's volume or retrieving unvalidated memory. When a workspace must survive a pause or restart, Northflank sandboxes support [persistent volumes](https://northflank.com/docs/v1/application/databases-and-persistence/add-a-volume). Your retention and authorization design should reflect the difference between [persistent and ephemeral AI sandboxes](https://northflank.com/blog/persistent-vs-ephemeral-ai-sandboxes). ### 7. Control images, dependencies, and tool supply chains The sandbox runtime, host integration, image bootstrap components, and deployment pipeline form part of the trusted computing base. Treat packages and tools installed inside the sandbox as potentially hostile inputs unless explicitly trusted. Require approved base images, build provenance, signature or attestation verification at admission, digest pinning where practical, controlled registries, patch ownership, and scanning. Apply policy to packages, plugins, MCP servers, tool definitions, and updates. Test the control with a malicious package, dependency confusion attempt, altered image tag, and hostile tool response. Scanning does not prove runtime behavior is safe. ### 8. Bound resources and make lifecycle cleanup reliable Put hard limits on both an individual sandbox and the tenant that can create it. Set CPU, memory, process, storage, output, network, duration, idle, and concurrency limits. Use leases and make lifecycle operations retry-safe. Deletion should remove compute, routes, temporary credentials, and ephemeral data while retained volumes follow a separate policy. Northflank exposes [sandbox lifecycle operations](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) for creation, status, commands, pause, resume, and deletion. Test those operations during load and partial infrastructure failure, not only in a clean demonstration. ### 9. Capture audit evidence without collecting private reasoning Record enough evidence to reconstruct why a run was allowed, what it affected, and how it ended. Correlate the initiator, agent and policy version, artifact, environment, policy decision, credentials, tool activity, approvals, affected resources, and termination reason. Capture inputs and outputs only where policy permits. Do not require private chain-of-thought. Keep application-level agent traces separate from platform events. Northflank [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) record the identity, source, time, parent events, and affected platform resources for supported changes. Your application must trace model, tool, and business-data activity. See how the layers fit together when you [govern AI-agent code execution](https://northflank.com/blog/govern-ai-agent-code-execution-enterprise). ### 10. Prove containment with adversarial and failure tests Security approval should depend on demonstrated failure behavior. Test prompt injection, tool confusion, malformed arguments, permission escalation, malicious dependencies and tool responses, memory poisoning, cross-tenant access, exfiltration, resource exhaustion, replay, approval bypass, persistence, and sandbox escape. During a live test, terminate the runtime, revoke its credentials, block its network paths, disable the relevant tool or policy, quarantine retained state, preserve evidence, and prevent another run. These controls must work independently of the agent and any system it can manipulate. ## Which sandbox security answers should block enterprise adoption? Block production adoption when a provider or internal platform cannot make its security boundary testable. Warning signs include an unexplained “isolated container” claim, shared human credentials, unrestricted egress, privileged host mounts, unowned persistent state, deletion without observable cleanup, platform logs that cannot correlate with agent activity, or a kill switch that only stops the model request. Also pause adoption when the team cannot identify where workload data, control-plane metadata, and telemetry travel. A missing feature is not always disqualifying. An unacknowledged boundary is. Record compensating controls, owners, and expiry evidence. ## How does Northflank support secure AI-agent sandboxes? Northflank provides an additional isolation boundary for untrusted execution alongside the platform controls needed to run agents beside APIs, workers, jobs, databases, and release workflows. - [Northflank sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) provide microVM-backed isolation for untrusted execution, while GPU workloads on Northflank Cloud use gVisor by default. Sandboxes support ephemeral roots or attached persistent storage. - [Enterprise identity controls](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation), RBAC, and scoped API roles restrict who or what can operate platform resources. - [Secret groups](https://northflank.com/docs/v1/application/secure/manage-secret-groups) control which workloads receive configured values, while deliberately configured private networking and BYOC network policies can restrict runtime connectivity. - [Audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) provide platform-side accountability that you can correlate with application agent traces. - The [API](https://northflank.com/docs/v1/api/use-the-api), [CLI](https://northflank.com/docs/v1/api/use-the-cli), [JavaScript client](https://northflank.com/docs/v1/api/use-the-javascript-client), and [Northflank Skills](https://github.com/northflank/skills) let approved automation operate the lifecycle through assigned permissions. Use [Northflank Cloud](https://northflank.com/cloud/northflank) when you want managed infrastructure. With self-serve [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud), workloads run in your cloud environment and you own the cloud account and infrastructure while Northflank manages platform orchestration. Available sandbox runtimes depend on provider and region, and Northflank-hosted control-plane metadata remains outside the workload-data boundary. Northflank is [SOC 2 Type 2 compliant and HIPAA compliant](https://northflank.com/security), with BAAs supported under Enterprise contracts. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss sandbox architecture, isolation, networking, data boundaries, and compliance requirements. ## Frequently asked questions about AI-agent sandbox security These answers address common enterprise sandbox decisions. ### Is a container enough to sandbox an AI agent? It depends on the threat model. A container may suit trusted, single-tenant automation with restricted inputs and privileges. Generated code, hostile inputs, unknown dependencies, or multi-tenant workloads may justify stronger isolation such as a separate-kernel microVM. ### Does a microVM make an AI agent safe? Not on its own. A microVM strengthens the runtime boundary, but the agent still needs scoped identity, secrets, network and data policy, resource limits, audit evidence, supply-chain controls, and independent containment. ### Does BYOC keep all sandbox data inside your cloud? Not necessarily. BYOC can place workload runtime and workload data in your cloud environment, but you must verify which control-plane metadata, logs, support data, and external service traffic cross that boundary. Northflank BYOC keeps workloads in your cloud while Northflank-hosted control-plane metadata remains outside that workload boundary. ### What should you test before allowing production access? Test prompt injection, malicious inputs and dependencies, permission escalation, cross-tenant access, disallowed egress, exfiltration, resource exhaustion, approval bypass, replay, persistence, sandbox escape, and the complete containment procedure. Grant more authority only after the platform passes tests shaped like your production workload. ## Related articles about secure AI-agent sandboxes Use these guides to extend the checklist into architecture, data access, networking, lifecycle, and enterprise operations. - [Which platform is best for running AI-generated code securely at scale?](https://northflank.com/blog/best-platform-running-ai-generated-code-securely-at-scale) - [How to govern AI-agent code execution in enterprise environments](https://northflank.com/blog/govern-ai-agent-code-execution-enterprise) - [How to design networking for secure AI-agent sandboxes](https://northflank.com/blog/how-to-design-networking-for-secure-ai-agent-sandboxes) - [How to isolate AI agents that have access to company data](https://northflank.com/blog/how-to-isolate-ai-agents-with-company-data) - [Persistent vs ephemeral AI sandboxes](https://northflank.com/blog/persistent-vs-ephemeral-ai-sandboxes)

Preview environments for microservices: Architecture and common pitfalls

2026-09-03T15:30:00.000Z

A preview environment for a single frontend can be one deployment and one URL. For microservices, the preview has to assemble compatible service versions, routes, databases, queues, workers, secrets, and tests without allowing one pull request to interfere with another. The architecture below shows how to decide what each preview should contain and avoid the routing, data, migration, observability, cost, and cleanup problems that make microservices previews unreliable. ## TL;DR: Preview environments for microservices Preview environments for microservices work when each change produces a known, isolated application slice rather than a loose collection of branch deployments. - Model each preview as a versioned dependency graph. Record which services use branch builds and which reuse stable artifacts. - Separate what changed, what needs a new build, and what must run for the tested path. - Isolate service discovery, writable data, messaging namespaces, and callbacks within the preview wherever practical, and give it access only to scoped non-production secrets. - Test contracts, migrations, asynchronous workflows, failure handling, and end-to-end behavior, not only whether each container started. - Update one environment per pull request, cap its resources and lifetime, and delete everything it created when review ends. If your team needs to reproduce a complete microservices application for every pull request, [Northflank Preview Environments](https://northflank.com/product/preview-environments) can provision services, databases, jobs, volumes, and secret groups from reusable [Preview Blueprints](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints). You can give internal services private endpoints, expose only the reviewer-facing service, and use conditions to skip components a change does not need. New commits update the existing preview, while automatic cleanup and concurrency limits keep the fleet bounded. Run previews on [Northflank Cloud](https://northflank.com/cloud/northflank), or use self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud) when the workloads need to run in your cloud account and network. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss microservices architecture, preview isolation, cloud placement, security, or cost. ## Why are preview environments harder for microservices? Microservices previews are harder because the unit under test is an interaction among independently versioned components, not one container. Suppose a pull request changes the checkout API. Testing it may also require the web application, authentication service, payment mock, worker, queue, and database. Deploy only the API and you miss the customer journey. Rebuild everything and feedback becomes slow and expensive. Mixed versions add risk. A new API may expect a field that the stable worker does not understand, or a migration may break an unchanged consumer. The goal is a controlled application slice that reproduces affected interactions and makes shared dependencies explicit. ## What architecture should a microservices preview environment use? A microservices preview should use an environment controller that turns a pull request into an explicit runtime manifest, provisions the required application slice, validates it, and owns its deletion. ### 1. Trigger and change resolver Start by answering three different questions: 1. **What changed?** Compare the branch with its merge base to find changed files, packages, schemas, or infrastructure definitions. 2. **What needs a new build?** Follow direct and transitive dependencies to find services affected by those changes. 3. **What must run?** Select the complete set of services and state required to exercise the relevant workflow. Those sets rarely match. A shared library may require three new builds, while the user journey needs eight running services. In a monorepo, path filters and a dependency graph can resolve affected builds. With separate repositories, the orchestrator needs an approved version policy for every other service. ### 2. Artifact and version resolver Build each affected service once per relevant commit and deploy immutable images. Unchanged dependencies should normally reuse a known image from the target environment or an approved baseline rather than rebuild their default branches for every preview. Record the image digest, configuration version, schema version, and commit so a passing test identifies the exact combination tested. Pinning those versions prevents dependencies changing halfway through review. ### 3. Environment orchestrator Treat the environment as one declarative unit containing services, jobs, state, configuration, routes, policies, and teardown. Creation should reach a defined ready state or show which dependency failed. If your team wants that definition managed alongside application delivery, Northflank provides [Preview Blueprints](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) that can create multiple services, database addons, seed jobs, volumes, and secret groups from Git and other supported triggers. You can [run migrations as workflow jobs](https://northflank.com/docs/v1/application/release/run-migrations) before or after deployment according to your compatibility strategy, then gate subsequent steps on success. A reusable definition gives every pull request the same topology and lifecycle rules. ### 4. Private service network and public entrypoint Every dependency intended to be isolated must resolve to its preview-local instance. Declare any shared dependency explicitly, pin its version where possible, and prevent cross-preview writes or namespace collisions. Hardcoded staging URLs are one of the easiest ways for an apparently isolated preview to write into a shared environment. [Kubernetes Services](https://kubernetes.io/docs/concepts/services-networking/service/) provide stable endpoints for changing groups of Pods, while [Kubernetes DNS](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/) lets workloads resolve Services by name. At the environment layer, use a separate namespace, project, or equivalent scope and generate service addresses from the preview identity. On Kubernetes, combine namespaces with [NetworkPolicies](https://kubernetes.io/docs/concepts/services-networking/network-policies/), RBAC, resource quotas, and preview-specific service accounts where stronger isolation is required. Expose only the gateway, frontend, or API surface reviewers require, and authenticate reviewer-facing URLs when the application or test data is not public. For private service-to-service communication, Northflank's [microservices Preview Blueprint pattern](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) keeps internal services private and exposes the external entrypoint. Payment and identity test systems must return to the correct preview URL, and their callback registrations must be removed during teardown. ### 5. Isolated state and asynchronous dependencies Choose the lightest data boundary that can prove the change works. | Data strategy | Best fit | Main risk | | --- | --- | --- | | Fresh schema with fixtures | Common workflows and deterministic automated tests | Fixtures may miss production-shaped cases | | Synthetic dataset | Repeatable tenant, role, and edge-case scenarios | Generators need active maintenance | | Fork or snapshot of non-production | Query, migration, and realistic state testing | Startup, storage, freshness, and data controls | | Shared read-only dependency | Stateless consumers and low-risk UI changes | Weaker isolation and limited write-path testing | Do not let multiple previews share the same writable schema or an unrestricted database identity. One migration or cleanup job can invalidate every other active review. Northflank Preview Blueprints can create a fresh database and run a seed job, or [fork a PostgreSQL, MongoDB, or MySQL addon from a compatible backup](https://northflank.com/docs/v1/application/databases-and-persistence/fork-an-addon) when the test needs realistic non-production state. Apply the same reasoning to asynchronous systems. Give the preview an isolated broker or preview-specific topics, queues, consumer groups, and routing keys. On a shared broker, enforce those namespaces with access controls or preview-scoped credentials, then set retention and cleanup for queues, topics, consumer groups, and dead-letter destinations. Redirect email, payment, and webhook side effects to test endpoints. An HTTP success is not an end-to-end success if its event went to a shared worker. ### 6. Validation and observability Mark the preview ready only after its required services can serve traffic and an environment-level smoke test can complete the tested path. Keep workload readiness checks shallow so one failing downstream service does not make every caller unready. Startup, liveness, and readiness probes answer different questions. [Kubernetes readiness probes](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes) can keep traffic away from a container that is running but not ready. Run contract and end-to-end tests after infrastructure readiness. Include relevant failure cases such as an unavailable downstream service, migration failure, recovery from a pre-migration backup, and retries. Propagate trace context across HTTP calls and messages so one test can be followed through the stack. [OpenTelemetry context propagation](https://opentelemetry.io/docs/concepts/context-propagation/) connects telemetry across service boundaries when producers inject context and consumers extract it using compatible instrumentation or propagators. Add the preview ID, pull-request ID, service version, and environment name to logs, metrics, and traces. If your team needs build and runtime visibility in the same platform, Northflank provides [live and historical logs and metrics](https://northflank.com/docs/v1/application/observe/observability-on-northflank) for builds, deployments, and jobs. Application-level tracing still needs to be instrumented and sent to your chosen backend. ### 7. Lifecycle and policy controller By default, maintain one preview per active pull request and update it when new commits arrive. This gives reviewers a stable URL and stops a fast-moving branch from leaving a trail of old stacks. Limit previews, concurrent builds, replicas, compute, storage, and lifetime. Delete environments on close or merge, with inactivity expiry as a fallback. SaaS test tenants, callbacks, buckets, and DNS need explicit teardown. For managed lifecycle control, Northflank can [update previews from new commits and delete them](https://northflank.com/docs/v1/application/release/manage-preview-blueprints) on pull-request close, merge, or inactivity. The same guidance recommends smaller preview plans and maximum concurrent preview limits to control cost. ## Which services should each preview deploy? Each preview should deploy the smallest application slice that preserves the behavior and risk being tested. | Model | Best fit | Principal risk | | --- | --- | --- | | Fully isolated stack | Cross-service, schema, security, and asynchronous changes | Highest startup time and cost | | Hybrid preview | Most feature work, with changed and stateful components isolated | Shared dependencies can drift or collide | | Shared dependency environment | UI changes and stateless consumers with stable contracts | Weakest end-to-end isolation | A hybrid model is often the practical default: deploy branch builds for affected services, pin stable images for unchanged services, isolate writable state, and share only controlled dependencies. Make these choices part of the preview definition rather than tribal knowledge. Northflank Preview Blueprints support [conditions and skipped node execution](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints), so a docs or frontend change can take a lighter path while a schema change provisions the complete stateful stack. ## What are the most common microservices preview environment pitfalls? The most common pitfalls come from treating a distributed application like a collection of independent deployments. 1. **Rebuilding every service.** This turns a small change into a fleet-wide CI job. Resolve affected builds and reuse pinned artifacts for everything else. 2. **Deploying only the changed service.** A green health check does not prove the user journey. Deploy the complete runtime slice needed for the test. 3. **Leaking into staging.** Hardcoded URLs, shared credentials, queue names, or callback registrations break isolation. Generate preview-local endpoints and use scoped non-production credentials. 4. **Running unsafe migrations.** Old and new service versions may coexist during a release. Prefer backward-compatible expand-and-contract changes, run migrations as explicit workflow steps, and test the forward migration and recovery strategy. Do not assume every migration can be reversed safely after new-version writes. 5. **Ignoring asynchronous paths.** Workers, retries, scheduled jobs, and dead-letter handling often contain the actual failure. Include them in the topology and acceptance test. 6. **Declaring readiness too early.** Container startup is not application readiness. Gate access on required dependencies, migrations, seed jobs, and smoke tests. 7. **Exposing secrets to untrusted pull requests.** Branch code can read variables, call metadata endpoints, or send credentials over the network. Do not inject privileged or production secrets into untrusted builds. Use preview-specific identities, least-privilege permissions, short-lived credentials, controlled egress, and approval gates for external contributions. 8. **Deleting only compute.** External test tenants, snapshots, volumes, DNS, and callback registrations can survive the preview. Give every created resource an owner, expiry, and deletion path. ## How does Northflank support preview environments for microservices? Northflank maps pull requests and branches to repeatable Preview Blueprints, with webhook, label, and manual triggers also available. - **Model the application slice:** Define services, databases, jobs, volumes, secrets, and routes in one [Preview Blueprint](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints). - **Configure selective builds:** Use per-service [path rules](https://northflank.com/docs/v1/application/build/build-code-from-a-git-repository) and Preview Blueprint conditions to rebuild the components your dependency rules identify while creating the required runtime topology. - **Keep traffic and configuration scoped:** Use internal endpoints and [secret groups](https://northflank.com/docs/v1/application/secure/manage-secret-groups) restricted by resource or preview tag. - **Inspect and remove previews:** View runtime status, update on later commits, and clean up on merge, close, or inactivity. Run this workflow on [Northflank's managed infrastructure](https://northflank.com/cloud/northflank) or in your cloud account with [BYOC](https://northflank.com/features/bring-your-own-cloud). Your team still defines dependencies, baseline versions, test data, migrations, tests, limits, and merge gates. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your service topology, preview concurrency, data isolation, networking, or cloud requirements. ## Frequently asked questions about preview environments for microservices ### Does every microservice need a separate instance in every preview? It depends on the change and the isolation it requires. Create separate instances for services that changed, own required mutable state, or could cause collisions. Stable services with controlled contracts can be pinned, shared, or mocked. ### How do preview environments work when microservices use separate repositories? Use the triggering commit for the changed service and resolve every dependency to an approved image version. One environment definition can assemble artifacts from separate repositories. ### Should a microservices preview use production data? Not by default. Prefer fixtures, synthetic records, or isolated non-production snapshots. If production-shaped data is necessary, minimise and mask it, restrict access, enforce residency and retention requirements, record access where policy requires it, and delete the data with the preview. Never give the preview production credentials. ### Can contract tests replace a full preview environment? For some changes, yes. Contract tests may be enough for low-risk interface changes, but they do not validate runtime routing, deployment configuration, migrations, message delivery, callbacks, or a complete user journey. Use a full preview when those properties are material to the change. ### How do you keep microservices preview environments affordable? Rebuild affected services only, reuse pinned artifacts, use smaller plans, cap concurrency, and delete previews automatically. Track stateful resource lifetime as closely as compute. ## Related articles about preview environments for microservices - [How do preview environments scale for AI-generated code?](https://northflank.com/blog/scale-preview-environments-ai-generated-code) - [How to build efficient monorepo preview environments](https://northflank.com/blog/how-to-build-efficient-monorepo-preview-environments) - [How to auto-create preview environments on every PR](https://northflank.com/blog/how-to-auto-create-preview-environments-on-every-pr) - [Which database strategy should you use for preview environments?](https://northflank.com/blog/which-database-strategy-should-you-use-for-preview-environments) - [Ephemeral testing environments](https://northflank.com/blog/ephemeral-testing-environments)

Which platforms support forward-deployed control planes?

2026-09-02T16:00:00.000Z

Running workloads in your own cloud does not always satisfy the strictest infrastructure policies. Your security team may also require the platform API, scheduler, deployment state, logs, and administrative workflows to remain inside a customer-controlled VPC, data centre, or disconnected environment. A forward-deployed control plane addresses that requirement by placing the platform's management layer inside your boundary. The available options differ in what they manage, who operates them, and whether they provide a complete application platform or a self-managed Kubernetes control plane. ## TL;DR: Which platforms support forward-deployed control planes? Representative platforms that support a customer-hosted or forward-deployed control plane include Northflank Enterprise, Red Hat OpenShift Container Platform, SUSE Rancher Prime, and Google Distributed Cloud air-gapped. The products use different terminology and cover different platform layers, so inclusion does not imply that they are interchangeable or that the list is exhaustive. - **Northflank Enterprise** explicitly supports a forward-deployed application control plane for customer-VPC, data-centre, zero-egress, and air-gapped requirements. It combines the local boundary with a developer platform for services, jobs, databases, storage, previews, workflows, sandboxes, and GPUs. - **Red Hat OpenShift Container Platform** keeps its Kubernetes and platform control planes on customer-managed infrastructure and supports disconnected installations. Connected installations can still communicate with Red Hat services; disconnected operation requires the relevant registry, content-mirroring, and update configuration. Red Hat calls this self-managed OpenShift, not a forward-deployed control plane. - **SUSE Rancher Prime** lets you install Rancher Manager, its Kubernetes fleet-management plane, on a customer-controlled cluster. It manages Kubernetes rather than providing the same integrated application-platform scope as Northflank or OpenShift. - **Google Distributed Cloud air-gapped** places an integrated cloud stack on premises without requiring connectivity to Google Cloud during operation. Its operating model can involve Google, a trusted partner, or a combination of the two. If your enterprise needs the application platform itself to operate inside its VPC, data centre, or restricted network, [Northflank Enterprise](https://northflank.com/enterprise) supports forward-deployed control planes, including zero-egress and air-gapped configurations. Your developers retain one platform for deploying services, jobs, databases, storage, preview environments, sandboxes, and GPU workloads while your organisation controls the infrastructure and network boundary. This is separate from standard [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud), which places workloads in your cloud account while Northflank provides the managed control plane, and [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok), which connects eligible existing Kubernetes infrastructure. That range lets you choose the strictest boundary your policies actually require without forcing every team into a self-managed platform. [Get started with Northflank](https://app.northflank.com/signup) to explore the platform self-serve. For a forward-deployed control plane, [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, air-gapped deployment, or migration requirements. ## What is a forward-deployed control plane? A forward-deployed control plane is a vendor's management or orchestration layer deployed inside customer-controlled infrastructure. It can manage scheduling, policy, cluster lifecycle, releases, identity, secrets, telemetry, and infrastructure operations without depending on a shared external control plane. The term is not yet a consistent industry category. Some vendors say `self-hosted controller`, `private management plane`, `on-premises`, `disconnected`, or `air-gapped`. Here, forward-deployed is a practical architectural category based on where the management plane runs; it is not necessarily the vendor's product terminology. Several adjacent architectures do not meet that definition. A platform can run workloads in your cloud while retaining its control plane as SaaS. An agent can reconcile resources locally while receiving desired state from a vendor service. Private connectivity can protect a network path without moving the management plane. Location also does not determine who operates the platform. A vendor may operate a control plane in your account, or your team may install, upgrade, back up, and recover it. That responsibility boundary affects cost and reliability more than the label. ## How should you compare forward-deployed control-plane platforms? Compare the boundary and the work your team inherits before comparing interfaces or feature lists. 1. **What runs inside your environment?** Trace the API, scheduler, state store, builds, registry, telemetry, identity, licensing, and support path separately. 2. **Who operates the control plane?** Establish responsibility for installation, upgrades, backups, scaling, security patches, incident response, and disaster recovery. 3. **Can it operate without egress?** Restricted egress, zero egress, disconnected operation, and a fully air-gapped deployment impose different requirements. 4. **What does the control plane manage?** A cluster manager, GitOps controller, and application platform solve different layers of the problem. 5. **What experience do developers receive?** Check whether teams get application abstractions, databases, releases, previews, logs, and self-service or must work directly with Kubernetes and infrastructure code. 6. **What governance is local?** Confirm how SSO, RBAC, policy, secrets, audit events, workload identity, and network controls behave inside the boundary. 7. **How is the deployment supported?** Define remote access, break-glass procedures, diagnostic exports, update delivery, and service-level commitments before production. If you only need workloads and workload data in your account, a conventional managed BYOC model can provide a smaller operating burden. The distinction between [BYOC, self-hosting, and managed cloud](https://northflank.com/blog/byoc-vs-self-hosting-vs-managed-cloud) should therefore be resolved before making a local control plane mandatory. ## How do representative customer-hosted control-plane options compare? | Platform | Control-plane model | Primary scope | Operating model | Best fit | | --- | --- | --- | --- | --- | | Northflank Enterprise | Forward-deployed in customer infrastructure | Full application and infrastructure platform | Defined with Northflank under Enterprise terms | Running production applications with a local platform boundary and managed-platform experience | | Red Hat OpenShift Container Platform | Self-managed platform and Kubernetes control planes | Kubernetes application platform | Customer operated with vendor support | Organisations standardising on a supported self-managed Kubernetes platform | | SUSE Rancher Prime | Rancher Manager installed on customer-controlled Kubernetes | Kubernetes cluster management | Customer-operated installation | Managing Kubernetes clusters through a local Rancher server | | Google Distributed Cloud air-gapped | On-premises infrastructure, data-plane, and management-plane networks | Integrated on-premises cloud platform | Operated by Google, a trusted partner, or a combination of the two | Operating regulated workloads without Google Cloud connectivity | ## Which platforms can put the control plane in your environment? The right platform depends on whether you need a complete developer platform, a self-managed Kubernetes application platform, multi-cluster management, or an integrated air-gapped cloud stack. ### 1. Northflank Enterprise Northflank Enterprise is the most direct fit when you need a forward-deployed control plane and a complete developer platform rather than another Kubernetes management layer. The [forward-deployed Enterprise option](https://northflank.com/docs/v1/application/enterprise) places the Northflank control plane inside your customer-controlled boundary and supports advanced requirements including zero-egress and air-gapped operation. Exact platform-operation, update, support, and access responsibilities should be defined for the chosen configuration and contract. The main difference is what the control plane gives your teams. Developers can deploy [services and jobs](https://northflank.com/docs/v1/application/run/run-containers-and-micro-services), [databases and persistent storage](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), [preview environments](https://northflank.com/product/preview-environments), [release workflows](https://northflank.com/docs/v1/application/release/continuous-integration-and-delivery-on-northflank), [sandboxes](https://northflank.com/product/sandboxes), and [GPU workloads](https://northflank.com/docs/v1/application/gpu-workloads/gpus-on-northflank) through the same platform. Platform teams retain identity, networking, policy, [observability](https://northflank.com/docs/v1/application/observe/observability-on-northflank), [audit](https://northflank.com/docs/v1/application/observe/audit-logs), and infrastructure controls. Northflank also provides less restrictive deployment models through the same product family. [Northflank Cloud](https://northflank.com/cloud/northflank) is the fully managed option. [BYOC](https://northflank.com/features/bring-your-own-cloud) puts Kubernetes and workloads in your cloud account while Northflank operates the remote platform layer. [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok) connects eligible existing Kubernetes. A forward-deployed control plane is reserved for policies that require the management layer itself to move inside the boundary. That range is useful when one organisation has several assurance levels. A general application can use managed cloud, a regulated workload can use BYOC, and a disconnected environment can use a forward-deployed control plane without giving developers unrelated deployment systems. Your platform team can standardise deployment, governance, and operations while security teams apply the infrastructure boundary each workload requires. For enterprises comparing Northflank with a self-managed platform, the decision is not simply where the software runs. It is whether your teams want to build and maintain the developer portal, application abstractions, release automation, data services, policy integrations, and operational tooling around Kubernetes. [Northflank for Enterprise](https://northflank.com/enterprise) provides that platform layer with direct engineering support. Northflank Enterprise includes a 99.99% uptime SLA; confirm how it applies to the selected forward-deployed configuration and any customer-controlled infrastructure dependencies. [Get started with Northflank](https://app.northflank.com/signup) to explore the platform self-serve. For a forward-deployed control plane, [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, air-gapped deployment, or migration requirements. ### 2. Red Hat OpenShift Container Platform Red Hat OpenShift Container Platform fits organisations that want a supported, self-managed Kubernetes application platform on their own infrastructure. The OpenShift and Kubernetes control planes run in the customer's environment. Connected installations can still communicate with Red Hat services, so a local control plane should not be treated as proof of a disconnected boundary. OpenShift supports disconnected installations, but they require additional preparation for registries, mirrored content, operators, and updates. It also adds developer and operational capabilities above upstream Kubernetes. Red Hat describes this as a self-managed model. In practice, your team must assign responsibility for installation, upgrades, capacity, availability, integrations, and incident response rather than assuming a vendor-operated platform lifecycle. ### 3. SUSE Rancher Prime SUSE Rancher Prime fits organisations that need a locally hosted management plane for multiple Kubernetes clusters. Rancher Manager can be installed on customer-controlled Kubernetes and used to manage downstream clusters. This places the Rancher Manager server inside your infrastructure, while the exact boundary still depends on the external integrations and data flows you configure. Rancher Prime primarily manages Kubernetes. Your organisation still needs to assemble or select the developer-facing layer for builds, application abstractions, databases, preview environments, and release workflows. The result is a customer-hosted Kubernetes management plane rather than an integrated developer platform. ### 4. Google Distributed Cloud air-gapped Google Distributed Cloud air-gapped fits regulated or sovereignty-sensitive environments that cannot depend on Google Cloud connectivity during operation. The infrastructure and services run on premises, and the product requires no connectivity to Google Cloud during operation. Google describes it as a fully managed experience operated by Google, a trusted partner, or a combination of the two. It supports Kubernetes and virtual-machine workloads. Google Distributed Cloud air-gapped is the least like-for-like entry. It is an integrated cloud infrastructure product, not a control plane added to an existing application stack. For an initial installation, Google documents downloading the software from the internet to a staging area and transferring it to the air-gapped environment using portable media. Evaluate hardware, site operations, capacity, releases, and support together. ## Which forward-deployed control-plane platform is best for your requirements? The best option is the one that meets your non-negotiable boundary without transferring unnecessary platform work to your team. - Use **Northflank Enterprise** when security or compliance policies require the control plane inside your environment, but you still want an integrated developer platform with direct engineering support, without your platform team having to build and operate the application delivery layer around Kubernetes. - Use **Red Hat OpenShift Container Platform** when your organisation already wants to own a supported Kubernetes application platform as an internal capability. - Use **SUSE Rancher Prime** when a self-hosted Kubernetes fleet-management plane is the central requirement. - Use **Google Distributed Cloud air-gapped** when operating without public-cloud connectivity requires an integrated local cloud stack rather than application-platform software alone. Before selecting a product, ask for an architecture diagram, data-flow inventory, responsibility matrix, upgrade procedure, disaster-recovery design, and disconnected-operation test. Revoke vendor access, interrupt external connectivity, restore control-plane state, rotate credentials, deploy a rollback, and confirm what evidence remains available. If your company is a SaaS vendor placing software in many customer accounts, the problem extends beyond one local control plane. You also need repeatable onboarding, version rings, configuration overrides, fleet health, and audited support access. Northflank's [Customer VPC Deployments](https://northflank.com/product/customer-vpc-deployments) addresses that wider customer-environment lifecycle. ## Frequently asked questions about forward-deployed control planes ### Is a forward-deployed control plane the same as BYOC? No. BYOC usually means workloads or the data plane run in your cloud account, while the vendor may retain a hosted control plane. A forward-deployed model places the management control plane itself inside your environment. ### Is a forward-deployed control plane self-hosted? Not necessarily. `Forward-deployed` describes location, while `self-hosted` usually describes operational responsibility. A vendor can operate software deployed in your environment, or your team can operate it under a software subscription. ### Can a forward-deployed control plane work in an air-gapped environment? Some can, but local placement alone is insufficient. Air-gapped operation also requires offline installation and updates, local identity and image dependencies, internal observability, local licensing behaviour, backup and recovery procedures, and a support process that does not depend on vendor connectivity. ### What data should remain inside the customer environment? Start with control-plane state, workload data, credentials, application and infrastructure logs, audit events, images, backups, and administrative traffic. Then identify permitted exceptions for licensing, support bundles, anonymised telemetry, or update checks. The answer should be an explicit data-flow design rather than a blanket `everything stays local` claim. ### Does Kubernetes already provide the control plane you need? Kubernetes provides a cluster control plane, but it does not automatically provide an enterprise application platform or a multi-cluster management plane. You may still need developer self-service, builds, releases, databases, secrets workflows, identity integration, policy, fleet management, observability, and support processes. ## Related articles about private and customer-controlled platforms - [BYOC vs self-hosting vs managed cloud](https://northflank.com/blog/byoc-vs-self-hosting-vs-managed-cloud) - [SaaS deployment in customer environments](https://northflank.com/blog/saas-deployment-in-customer-environment) - [How to deploy SaaS in a customer VPC](https://northflank.com/blog/deploy-saas-in-customer-vpc) - [How to manage SaaS deployments across customer VPCs at scale](https://northflank.com/blog/how-to-manage-saas-deployments-across-customer-vpcs-at-scale) - [How to create a Vercel-like developer experience for on-premises deployments](https://northflank.com/blog/vercel-like-developer-experience-for-on-premises-deployments)

How should an enterprise IDP support AI-generated software?

2026-09-02T15:59:00.000Z

AI coding tools can produce applications faster than teams can review, deploy, and operate them. The risk is not that AI touched the code. It is that software can reach company systems without a named owner, security checks, defined access rules, or a plan for maintenance and removal. An enterprise internal developer platform (IDP) should apply the same deployment requirements to AI-generated and human-written software, adding automation and isolation when AI acts with delegated permissions or generates code at runtime. This article explains what the IDP should require, test, restrict, deploy, monitor, and remove. ## TL;DR: How should an enterprise IDP support AI-generated software? An enterprise IDP should support AI-generated software by giving developers and coding agents one controlled route from a code change or container image to a secure, monitored application with a named owner. - Require the same application and deployment information for ownership, source code, runtime, data access, environments, and retirement, regardless of which AI tool produced the code. - Automate test records and deployment-rule checks so increased code volume does not create a manual approval queue. - Give coding agents distinct identities with limited permissions; permission to generate a change must not silently become permission to release it. - Validate changes in disposable full-stack environments, promote the same tested container image where practical, and preserve rollback. - Apply stronger isolation when software generates or executes untrusted code at runtime, and automate cost tracking, expiry, and retirement. If your enterprise needs one controlled deployment route for software produced by developers and coding agents, [Northflank's internal developer platform](https://northflank.com/product/idp) brings builds, services, jobs, databases, and release automation together. Platform teams can encode application designs in [infrastructure-as-code templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code), create [preview environments](https://northflank.com/product/preview-environments) for generated changes, and use [Workflows](https://northflank.com/docs/v1/application/release/configure-workflows) to control how tested releases move between environments. Applications that execute generated or untrusted code at runtime can add [microVM-backed sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank). Your teams can use the UI, API, CLI, GitOps, or templates through Northflank. Run applications on managed [Northflank Cloud](https://northflank.com/features/managed-cloud), or use [Northflank BYOC](https://northflank.com/product/bring-your-own-cloud) when applications and their data need to remain in your cloud account. [Northflank Skills](https://github.com/northflank/skills) give coding agents instructions for deploying and operating applications. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## What changes when AI starts producing enterprise software? AI coding tools can increase software output, introduce non-human actors, and expand the application inventory. Your enterprise remains responsible for what reaches production. | Software class | What AI produces | IDP implication | | --- | --- | --- | | AI-assisted software | Source code before the normal build and deployment process | Use the standard deployment process, with automated test records and controls based on the application's risk | | Runtime-generated code | Code, commands, or packages executed after deployment | Add a separate execution boundary with tighter resource, credential, network, state, and termination controls | Who wrote the code is a weak measure of risk. Your IDP should base controls on data sensitivity, public exposure, business impact, access to critical systems, and runtime behaviour instead of creating one slow lane for anything labelled “AI-generated.” The [AI-native IDP and AI software development lifecycle](https://northflank.com/blog/ai-sdlc) can increase delivery speed while the IDP controls how a proposed change becomes a running application. ## What should an enterprise IDP require from AI-generated software? An AI-ready IDP should require a consistent description of the application and where it may run, regardless of which coding tool created it. An editor plugin or agent integration should not become the authoritative record of what is running. For every application, require enough information to answer: - What repository revision, build definition, or container image is entering the platform? - Who owns the software, what purpose does it serve, and who may use it? - Which service, job, database, storage, and runtime resources does it need? - What data classifications, private dependencies, ingress, and egress rules apply? - Which preview, development, staging, and production environments may it enter? - When should an experiment be reviewed, archived, or removed? Collect this information through a repository file, API request, template, or portal, and enforce it during deployment. A catalog alone cannot stop an ownerless release. If your platform team wants to make approved application designs reusable, Northflank provides [infrastructure-as-code templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code) for application and infrastructure resources. Developers and automation can use the same Northflank platform through its UI, [API and CLI](https://northflank.com/docs/v1/api/introduction), templates, and [GitOps](https://northflank.com/docs/v1/application/infrastructure-as-code/gitops-on-northflank), so a coding agent does not need a separate deployment route with weaker controls. ## How should the IDP validate AI-generated changes without becoming a bottleneck? The IDP should automatically collect test and security results, reserving manual approval for changes whose impact justifies it. Start with the exact source-code revision and run the build in an isolated environment. Record the test and security results, the resulting container image, the rules that allowed or blocked the change, and its deployment status. Match these checks to the application's language, data, public exposure, and business criticality. Code review alone cannot confirm whether authentication, private APIs, migrations, jobs, and configuration work together at runtime. Test the running application in a disposable environment. If your enterprise needs that validation to include application dependencies, Northflank [preview environments](https://northflank.com/product/preview-environments) can create ephemeral full-stack environments for pull requests or feature branches, including services, jobs, and databases. Northflank [Workflows](https://northflank.com/docs/v1/application/release/configure-workflows) can then coordinate release actions and appropriate approval steps across environments. Promote the tested container image by immutable reference where practical. Retain the last known-good image, configuration, and rollback procedure separately. Record failure tests as well as successful tests. For a fuller release model, see [how to prevent AI-generated code from breaking production](https://northflank.com/blog/how-to-prevent-ai-generated-code-from-breaking-production). ## How should identity and production authority work for coding agents? Coding agents should use separate automation identities or API tokens with minimum permissions and duration. A developer, CI pipeline, coding agent, and application should not share one broad credential. Separate permission to propose, build, preview, release to production, and change security rules. An agent that creates a service may not need production secrets, and one that opens a pull request should not inherit the repository owner's permissions. High-impact releases may require a separate automated decision or human approval. If your enterprise needs to separate an agent's permissions from production release authority, Northflank [RBAC roles](https://northflank.com/docs/v1/application/secure/use-role-based-access-control) control UI and API access and can be restricted to specific projects. [API tokens](https://northflank.com/docs/v1/application/secure/grant-api-access) inherit those role permissions and can expire or be revoked immediately. [Workflow approval nodes](https://northflank.com/docs/v1/application/release/configure-workflows) can require team members to approve a release before production. Do not place secrets in prompts, generated source, or persistent agent context. Account for prompt and session retention when granting credential access. Inject secrets by environment and application identity. Operators must be able to stop a run, invalidate credentials, remove network access, and block further actions independently. If these controls need to be enforced through the deployment platform, Northflank can [inject secrets as runtime variables](https://northflank.com/docs/v1/application/secure/inject-secrets) and share selected values through secret groups. Teams can revoke an agent's API token, apply [path-based security policies](https://northflank.com/docs/v1/application/network/create-path-based-security-policies) to service ports, and [pause or destroy its sandbox](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) without relying on the agent to cooperate. If your enterprise needs central access control, [Northflank for Enterprise](https://northflank.com/enterprise) supports SSO, directory sync, granular RBAC, granular API permissions, and platform audit logs. [Northflank audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) show platform changes. They do not replace application monitoring or records of agent actions and results. ## When does AI-generated software need isolated execution? Not every AI-generated application needs a sandbox. Stronger isolation becomes relevant when a deployed application runs generated code, user-submitted code, untrusted packages, files, or shell commands. Treat code execution as a separate security boundary. Give each run the smallest useful filesystem, CPU, memory, duration, credentials, and network access. Prefer temporary storage, restrict outbound connections, and let operators terminate the run from outside it. Scope sensitive tokens to the requested action instead of copying all permissions from the parent service. A reviewed service may fit your standard container runtime. Multi-tenant or adversarial code execution may require a separate kernel boundary and stricter controls. If your application executes generated code at runtime, Northflank provides [microVM-backed sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) alongside the services, jobs, databases, and release processes around them. ## How should an AI-ready IDP control environments, data, and cost? An AI-ready IDP should separate preview, staging, and production access while making short-lived environments cheap to create and automatic to remove. Higher software volume makes expiry and removal rules an operational requirement, not housekeeping. Preview environments should reproduce the dependencies and configuration characteristics needed for the test without copying production data or credentials by default. A production release should use production-specific identities, secrets, network paths, capacity, data-retention rules, and recovery procedures. Expire experiments, shut down idle resources, assign costs to teams or applications, and flag services with no active owner or recent use. If full-stack validation needs consistent infrastructure, Northflank [preview environments](https://northflank.com/product/preview-environments) support ephemeral environments and idle-shutdown policies. [Preview environment templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code) are versionable, and Northflank automatically tears down the environment when its pull request is closed or merged. If your enterprise must keep deployed applications and their data inside its cloud account, [Northflank BYOC](https://northflank.com/product/bring-your-own-cloud) runs them within your cloud environment while retaining the Northflank developer experience. Review the [Northflank security and data boundaries](https://northflank.com/security) to decide where logs, metrics, builds, images, backups, and control-plane metadata should reside. ## How can Northflank support an enterprise IDP for AI-generated software? [Northflank's internal developer platform](https://northflank.com/product/idp) supports AI-generated software by giving developers, coding agents, platform engineers, and security teams a system for building, testing, releasing, and operating applications. This avoids a separate AI deployment stack and uncontrolled agent releases. - **Consistent developer and agent access:** Teams and agents can use the UI, [API and CLI](https://northflank.com/docs/v1/api/introduction), [GitOps](https://northflank.com/docs/v1/application/infrastructure-as-code/gitops-on-northflank), and versioned [infrastructure-as-code templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code). - **Complete application infrastructure:** Run [services](https://northflank.com/docs/v1/application/run/run-an-image-continuously), [jobs](https://northflank.com/docs/v1/application/run/run-an-image-once-or-on-a-schedule), [databases](https://northflank.com/docs/v1/application/databases-and-persistence/deploy-a-database), storage, previews, and release workflows together. - **Controlled validation and release:** Full-stack [preview environments](https://northflank.com/product/preview-environments) give generated changes a disposable test environment, while [Northflank Workflows](https://northflank.com/docs/v1/application/release/configure-workflows) control the steps used to deploy and promote them. - **Enterprise access:** [Northflank for Enterprise](https://northflank.com/enterprise) adds SSO, directory sync, RBAC, granular API permissions, and audit records for platform changes. - **Isolated runtime code execution:** [Northflank sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) add a microVM-backed boundary when an application executes generated or otherwise untrusted code. - **Infrastructure choice:** Use managed [Northflank Cloud](https://northflank.com/features/managed-cloud), run deployed applications and their data in your account with [Northflank BYOC](https://northflank.com/product/bring-your-own-cloud), or import eligible existing Kubernetes infrastructure with [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements). - **Agent-aware operations:** [Northflank Skills](https://github.com/northflank/skills) give compatible coding agents instructions for deploying and operating services, jobs, previews, workflows, sandboxes, and other Northflank resources. Northflank is [SOC 2 Type 2 compliant and HIPAA compliant](https://northflank.com/security), with BAAs supported under Enterprise contracts. Platform compliance does not automatically make an application compliant; its architecture, data use, access, and operations remain part of the assessment. Teams can start self-serve, then add enterprise controls. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## What should your enterprise implement first to support AI-generated software? Start with one low-risk AI-assisted application before adding tools, application types, and autonomy levels. First, define the minimum application and deployment requirements in one template. Next, automate the tests and records needed for build, preview, production, rollback, and retirement. Decide which changes can proceed automatically. Then expand by behaviour and risk. Add runtime-generated code after testing isolation, access revocation, outbound networking, and resource limits. Measure lead time, deployment failures, recovery time, rule exceptions, ownerless applications, expiry compliance, and cost attribution. Expand when the approved deployment route is easier to use and check than an unmanaged alternative. ## Frequently asked questions about enterprise IDPs and AI-generated software Controls depend on runtime behaviour. ### Does every AI-generated application need a sandbox? Not necessarily. AI-generated code that has been reviewed, tested, and built before deployment can use the same runtime isolation as comparable human-authored software. Stronger sandbox isolation is appropriate when an application executes generated code, user-submitted code, untrusted packages, files, or commands at runtime. ### Should coding agents be allowed to deploy to production? It depends on the agent's identity, permissions, test results, and potential impact. Allow automatic releases where deployment rules and tests justify them; require independent approval for higher-impact changes. Do not let permission to write code silently confer broad production access. ### Does an AI-ready IDP need a developer portal? Not necessarily. Teams can submit the required application information through a portal, API, CLI, GitOps, or templates. The deployment system must enforce the requirements. ### Can an existing IDP be adapted for AI-generated software? Often, yes. Keep traceable builds, reusable designs, separate environments, access controls, monitoring, and rollback. Add agent identities, automated tests, isolated execution where required, expiry, and retirement controls. ## Related articles about AI-native internal developer platforms - [The future of the AI-native internal developer platform and the AI SDLC](https://northflank.com/blog/ai-sdlc) - [How to prevent AI-generated code from breaking production](https://northflank.com/blog/how-to-prevent-ai-generated-code-from-breaking-production) - [Building an internal platform for AI-built applications](https://northflank.com/blog/building-an-internal-platform-for-ai-built-applications) - [Build vs buy an internal developer platform: costs, trade-offs, and ROI](https://northflank.com/blog/build-vs-buy-an-internal-developer-platform) - [How to build an internal developer platform (and why you might not want to)](https://northflank.com/blog/how-to-build-an-internal-developer-platform)

BYOC vs self-hosting vs managed cloud: Which deployment model should you choose?

2026-09-01T15:22:00.000Z

One team needs to ship a customer-facing application this week. Another must keep workloads inside an approved cloud account. A third operates in an environment where an external control plane is not permitted. These teams should not choose the same deployment model. The difference between bring your own cloud (BYOC), self-hosting, and managed cloud is not simply where software runs. It is who owns the infrastructure, who operates the platform, where workload data flows, and who responds when the underlying system fails. This guide compares those boundaries, costs, and enterprise use cases so you can choose the right model. ## TL;DR: BYOC vs self-hosting vs managed cloud Choose managed cloud when speed and low operational overhead are the priorities, BYOC when workloads must run in your cloud account but you still want a vendor-managed platform, and self-hosting when your organization must operate and control the stack. - **Managed cloud** is the best default for applications without a hard infrastructure ownership, residency, private-network, or hardware requirement. - **BYOC** often fits regulated workloads that require customer-owned infrastructure or a defined data boundary, but BYOC alone does not make a workload compliant. It can also support private integrations, cloud commitments, and compatible reserved GPU capacity. - **Self-hosting** fits air-gapped environments, unsupported infrastructure, deep platform customization, or policies that prohibit an externally managed control plane. - Product labels vary. Confirm who operates the control plane, Kubernetes, upgrades, backups, and incident response, plus which data leaves the workload environment. If your enterprise needs to change where workloads run without giving developers a different deployment workflow, [Northflank](https://northflank.com/) provides a managed application platform across [Northflank Cloud](https://northflank.com/cloud/northflank), self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud), eligible existing Kubernetes clusters through [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok), and forward-deployed control planes for stricter enterprise boundaries. Your teams keep the same deployment workflow while infrastructure ownership matches each workload's requirements. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## What is the difference between BYOC, self-hosting, and managed cloud? Managed cloud transfers infrastructure and platform operations to a provider. BYOC keeps the workload infrastructure in your cloud account while a vendor manages a defined platform layer. Self-hosting leaves your organization responsible for deploying and operating the software. | Decision | Managed cloud | BYOC | Self-hosting | | --- | --- | --- | --- | | Infrastructure or account owner | Provider | Customer | Customer or chosen infrastructure provider | | Platform operation | Provider | Vendor, within an agreed boundary | Customer | | Kubernetes operation | Provider | Vendor or customer, depending on the implementation | Customer | | Workload location | Provider infrastructure | Customer cloud, VPC, or approved environment | Customer-chosen cloud, private cloud, or on-premises infrastructure | | Infrastructure bill | Usually included in provider billing | Paid directly by customer | Paid directly by customer | | Time to production | Usually shortest | Moderate, with cloud integration required | Usually longest | | Customization | Within platform options | Cloud controls plus platform options | Maximum application-platform control; lower-layer control depends on the infrastructure | | Best fit | Speed and low operational load | Infrastructure control with managed platform operations | Maximum platform authority and operational responsibility | Self-hosting is an operational model, not a location. Software can be self-hosted in a public cloud, private data center, or edge environment. BYOC also has no universal architecture. One vendor may manage a remote control plane and a customer data plane. Another may place more platform components inside the customer account. Before procurement, ask for an architecture diagram and a responsibility matrix rather than relying on the label. ## When should you choose managed cloud? Choose managed cloud when your main requirement is to deploy and scale applications without operating the underlying platform. This model suits applications that fit the provider's regions and security boundary. Your team focuses on the application while the provider operates the platform. Confirm tenancy, connectivity, data processing, exports, and migration options. If your applications do not have a named reason to run elsewhere, Northflank provides [managed application infrastructure through Northflank Cloud](https://northflank.com/cloud/northflank). Services, jobs, databases, and deployment workflows run without your team operating Kubernetes. For selection guidance, see [what managed cloud hosting means for modern applications](https://northflank.com/blog/managed-cloud-hosting). ## When should you choose BYOC? Choose BYOC when the workload must run in your cloud account, VPC, region, or billing relationship, but you do not want to take over platform operations. The requirement usually comes from one or more concrete use cases: - Workloads must reach private services or remain in an approved account or region. - Your enterprise needs its own IAM, network, and cloud-security controls around the execution plane. - Workloads should consume committed cloud spend or compatible reserved GPU capacity. - Business units need separate accounts with a consistent developer platform. BYOC is the middle operational model. Your enterprise owns and pays for the infrastructure, while the vendor operates the platform components defined in the contract and architecture. If your enterprise needs that split, Northflank's self-serve [Bring Your Own Cloud platform](https://northflank.com/features/bring-your-own-cloud) provisions and manages Kubernetes in your [AWS](https://northflank.com/cloud/aws), [GCP](https://northflank.com/cloud/gcp), [Azure](https://northflank.com/cloud/azure), [Oracle Cloud](https://northflank.com/cloud/oci), [CoreWeave](https://northflank.com/cloud/coreweave), [Civo](https://northflank.com/cloud/civo), or [Nebius](https://northflank.com/cloud/nebius) account. Workloads run within your customer-owned network, regional, IAM-policy, and billing boundary, while Northflank receives defined privileges to handle cluster upgrades, scaling, maintenance, and application orchestration. With [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud), workload runtime and workload data reside in your environment, while control-plane metadata is Northflank-hosted. Logs, metrics, builds, images, and backups have configurable or category-specific locations. Review the current [security and data boundaries](https://northflank.com/security) rather than assuming every data category follows the workload. ## When should you choose self-hosting? Choose self-hosting when your organization must install, operate, modify, and recover the platform itself. That ownership may be justified for air-gapped systems, policies that prohibit vendor management connections, unsupported hardware, deep changes to platform behavior, or requirements that keep operational authority entirely in-house. Your platform team then owns installation, upgrades, vulnerability response, capacity, networking, observability, backups, recovery, and incidents. The relevant question is whether your organization wants to sustain that work through security events, staff turnover, and major upgrades. An existing Kubernetes team can use Northflank [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok) while Northflank manages workloads, networking, and observability. Imported clusters must meet [Northflank's BYOK requirements](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements). If the control plane must remain inside the enterprise boundary, [Northflank for Enterprise](https://northflank.com/enterprise) supports a forward-deployed control plane in the customer's VPC or data center, including zero-egress and air-gapped configurations. Confirm who operates, upgrades, and supports each component. A control plane running in your environment is not necessarily self-hosted; the distinction depends on who operates it. ## How should you compare total cost and operational risk? Compare the complete cost of operating the workload, not an isolated compute rate or platform fee. For managed cloud, include provider fees, transfer, storage, support, and dedicated resources. For BYOC, include the platform fee, cloud bill, networking, support, and internal responsibilities, then credit cloud commitments. For self-hosting, include platform staff, on-call coverage, upgrades, security, database and cluster operations, backup testing, recovery, compliance evidence, and observability. Risk has a cost too. Compare how quickly each model can restore service, patch a vulnerability, recover data, and produce audit evidence. No model is universally cheapest: the answer depends on staffing, scale, commitments, and the cost of operational work your enterprise accepts. ## Which deployment model fits each enterprise use case? Use the model that satisfies the workload's hardest boundary without transferring unnecessary operations to your team. | Enterprise use case | Strongest starting point | Why | | --- | --- | --- | | New SaaS product or internal application | Managed cloud | Fast route to production with minimal platform work | | Regulated workload in an approved cloud landing zone | BYOC | Workload runs within customer-owned regional, IAM-policy, and network boundaries | | Application using private databases and APIs | BYOC | Places compute close to private services while retaining managed platform operations | | Existing cloud commitments or compatible reserved GPUs | BYOC | Infrastructure bills to the customer account and can use supported capacity | | Existing Kubernetes platform with a dedicated operations team | Self-hosting or BYOK-assisted platform | Preserves cluster ownership while choosing how much application-layer operation to delegate | | On-premises or edge deployment | Self-hosting, BYOK, or forward-deployed platform | The right choice depends on cluster and control-plane responsibility | | Air-gapped defense or critical infrastructure environment | Self-hosting or a forward-deployed platform | The required operating boundary determines the choice | | Multi-cloud internal developer platform | BYOC | Keeps infrastructure in selected accounts while standardizing developer workflows | ## How does Northflank support managed cloud, BYOC, and private infrastructure? Northflank provides one application platform across managed and customer-controlled infrastructure. - **Managed infrastructure:** [Northflank Cloud](https://northflank.com/cloud/northflank) runs applications without requiring your team to operate the underlying Kubernetes environment. - **Customer-owned cloud:** Self-serve [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud) provisions and manages Kubernetes while your enterprise owns the cloud account and sets network, IAM-policy, regional, and billing boundaries. - **Existing infrastructure:** [Northflank BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/import-an-existing-cluster-byok) connects an eligible Kubernetes cluster that your team provisions and operates, including supported on-premises environments. The cluster must meet Northflank's connectivity and load-balancer requirements. - **Stricter control-plane boundaries:** [Northflank for Enterprise](https://northflank.com/enterprise) supports forward-deployed control planes for requirements that cannot use Northflank's managed control plane. - **Application lifecycle and governance:** Northflank provides [services](https://northflank.com/docs/v1/application/run/run-containers-and-micro-services), [jobs](https://northflank.com/docs/v1/application/run/run-an-image-once-or-on-a-schedule), [databases](https://northflank.com/docs/v1/application/databases-and-persistence/deploy-a-database), [CI/CD](https://northflank.com/docs/v1/application/release/ci-cd-on-northflank), [previews](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints), [secrets](https://northflank.com/docs/v1/application/secure/inject-secrets), [observability](https://northflank.com/docs/v1/application/observe/observability-on-northflank), [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), and [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs), with [enterprise SSO](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication) available for organizations. Developers and automation can use the UI, [API](https://northflank.com/docs/v1/api/use-the-api), [CLI](https://northflank.com/docs/v1/api/use-the-cli), [GitOps](https://northflank.com/docs/v1/application/infrastructure-as-code/gitops-on-northflank), and [Northflank Skills](https://github.com/northflank/skills); credentials, RBAC, and audit controls govern their actions. Start with the [BYOC and BYOK requirements](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements) and [BYOC setup guide](https://northflank.com/docs/v1/application/bring-your-own-cloud/use-other-cloud-providers-with-northflank), then follow the provider instructions for [AWS](https://northflank.com/docs/v1/application/bring-your-own-cloud/aws-on-northflank), [GCP](https://northflank.com/docs/v1/application/bring-your-own-cloud/gcp-on-northflank), [Azure](https://northflank.com/docs/v1/application/bring-your-own-cloud/azure-on-northflank), [Oracle Cloud](https://northflank.com/docs/v1/application/bring-your-own-cloud/oci-on-northflank), [CoreWeave](https://northflank.com/docs/v1/application/bring-your-own-cloud/coreweave-on-northflank), [Civo](https://northflank.com/docs/v1/application/bring-your-own-cloud/civo-on-northflank), or [Nebius](https://northflank.com/docs/v1/application/bring-your-own-cloud/nebius-on-northflank). Northflank is [SOC 2 Type 2 compliant and HIPAA compliant](https://northflank.com/security), with BAAs supported under Enterprise contracts. Teams can start self-serve on Northflank Cloud or BYOC, while enterprise requirements such as SSO, BAAs, or forward-deployed control planes follow their applicable access and contract terms. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss managed cloud, BYOC, existing Kubernetes, forward deployment, security, or migration requirements. ### How does Northflank pricing work for managed cloud and BYOC? [Northflank pricing](https://northflank.com/pricing) reflects where your workloads run and who supplies the infrastructure: - **Northflank Cloud:** Deploy workloads on Northflank's infrastructure and pay Northflank for compute at $0.01667/vCPU/hour and $0.00833/GB of memory/hour. The smallest compute plan provides 0.1 shared vCPU and 256 MB memory for $2.70 per container per month ($0.0038/hr). Network egress costs $0.06/GB, and disk costs $0.15/GB/month. - **BYOC:** Deploy to your own cloud accounts. Use your cloud credits and existing billing relationships. For BYOC, Northflank charges $0.01389/vCPU/hour and $0.00139/GB of memory/hour; your cloud provider bills the underlying infrastructure separately. High-scale/custom deployments may use Enterprise pricing. Northflank offers three pricing tiers: - **Free Sandbox:** Test Northflank with always-on compute that does not sleep, two free services, one free database, and two free cron jobs. - **Pay-as-you-go:** Pay only for consumption, prorated to the second without seat-based pricing. Deploy CPU and GPU workloads with support for 6+ Northflank cloud regions and 600 BYOC regions, and scale without a fixed resource ceiling. - **Enterprise:** Add invoicing, volume discounts, annual commitments, SLAs, 24/7 support, onboarding, and private or hybrid deployment options. Use the [pricing calculator](https://northflank.com/pricing#calculator) to estimate services, jobs, databases, volumes, builds, egress, and BYOC clusters. ## How do you make the final decision? Start with the least operationally complex model that meets the workload's non-negotiable requirements. Ask five questions in order: 1. Where must workloads, workload data, secrets, logs, and backups run? 2. Which external control-plane, support, or network connections are prohibited? 3. Who will own upgrades, scaling, security patches, backups, and incidents? 4. Do cloud commitments, reserved hardware, or existing platform staff materially change the economics? 5. How will you move workloads, configuration, and data if the requirement or vendor changes? Use managed cloud when no hard requirement moves the infrastructure boundary. Use BYOC when your enterprise must own that boundary but still wants the vendor to operate the platform. Choose self-hosting only when complete operational control is itself a requirement and your organization is prepared to sustain it. ## Frequently asked questions about BYOC, self-hosting, and managed cloud ### Is BYOC the same as self-hosting? No. A BYOC vendor continues to manage a defined platform layer, while a self-hosting team deploys and operates the software. Confirm the control-plane, cluster, and incident-response boundary. ### Does BYOC keep all data in your cloud account? Not necessarily. BYOC can keep workloads and workload data in your cloud account, but control-plane metadata, telemetry, support diagnostics, or build information may follow a different path. Map each data category to the vendor's actual architecture and data flow. ### Is self-hosting always cheaper than managed cloud? No. Self-hosting may reduce vendor fees but adds engineering, security, upgrades, backups, observability, on-call response, and recovery work. Compare total workload cost and operational risk rather than compute alone. ### Can you move from managed cloud to BYOC later? It depends. Check whether images, databases, networking, secrets, and release workflows are portable between environments. Northflank uses the same platform workflows across Northflank Cloud and BYOC. ### What is the difference between BYOC and BYOK? In Northflank's implementation, BYOC means Northflank provisions and manages a Kubernetes cluster in your cloud account. BYOK means Bring Your Own Kubernetes: you import an eligible cluster and retain responsibility for its underlying lifecycle while Northflank manages workloads, networking, and observability. ## Related articles about BYOC and cloud deployment models - [What is BYOC in cloud computing?](https://northflank.com/blog/what-is-byoc-in-cloud-computing) - [Is BYOC the future of software deployment?](https://northflank.com/blog/is-byoc-the-future-of-software-deployment) - [What is managed cloud hosting?](https://northflank.com/blog/managed-cloud-hosting) - [How to deploy AI-built applications securely in your own cloud](https://northflank.com/blog/securely-deploy-ai-applications-in-your-cloud): Security controls for AI-built applications. - [What is an enterprise container platform?](https://northflank.com/blog/what-is-an-enterprise-container-platform): Enterprise container-platform layers.

How to replace a DIY internal developer platform without disrupting software delivery

2026-09-01T15:20:00.000Z

Replacing a DIY internal developer platform can be risky because it sits in the path from commit to production. A big-bang cutover can turn one platform failure into blocked releases, inconsistent environments, and incidents across every team that depends on it. A safer approach preserves the workflows, interfaces, and delivery outcomes developers depend on while the replacement runs beside the existing platform. Workloads move in cohorts, and teams retire components only after validating delivery and rollback. This requires coordinated decisions about releases, stateful dependencies, enterprise controls, and decommissioning. This article covers planning a phased migration, validating workloads, managing critical dependencies, and safely decommissioning the old platform. ## TL;DR: How to replace a DIY internal developer platform Replace a DIY internal developer platform without pausing software delivery by running a phased migration in which the old and new delivery paths coexist. - Preserve familiar developer workflows and expected delivery outcomes before changing the implementation underneath them. - Baseline build, deploy, rollback, recovery, and support performance so the replacement has measurable acceptance criteria. - Reproduce a representative workload, including its database, secrets, networking, observability, and release process. - Migrate by risk cohort and keep routing and release rollback independent of the new platform. - Remove old write paths before decommissioning the old platform, then observe long enough to find scheduled and rarely used dependencies. If your enterprise wants to replace the custom build, deployment, environment, and release systems behind its DIY internal developer platform, Northflank provides [composable infrastructure and application primitives](https://northflank.com/product/idp) for builds, services, jobs, databases, preview environments, and release automation. Teams can access these capabilities through the UI, API, CLI, GitOps, and templates, allowing Northflank to integrate with existing developer workflows. Northflank offers two infrastructure models. [Northflank Cloud](https://northflank.com/features/managed-cloud) provides managed infrastructure, while [bring your own cloud (BYOC)](https://northflank.com/product/bring-your-own-cloud) runs workloads in your cloud account, where your team retains control over networking, regional placement, capacity, and cloud-provider billing. With BYOC, workloads remain in your cloud account as you replace the DIY internal developer platform. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your platform replacement requirements. ## Why can replacing a DIY internal developer platform disrupt delivery? Replacing a DIY internal developer platform can disrupt delivery when teams underestimate how many systems and dependencies it coordinates. The portal may be visible, but scripts, controllers, credentials, cluster conventions, pipeline stages, and manual operating procedures perform the work underneath it. | Hidden dependency | Delivery risk during replacement | | --- | --- | | Build and artifact flow | Different images, provenance, caching, or promotion behavior | | Environment conventions | Missing configuration, inconsistent resource sizing, or incorrect domains | | Secrets and identity | Overprivileged access or workloads that cannot start | | Networking and DNS | Failed private connections, callbacks, or service discovery | | Data services | Incompatible schema changes, backups, or restore procedures | | Observability and operations | Incidents that the new alerts, dashboards, or runbooks do not detect | Manage the replacement as a software delivery migration, not a portal launch. Teams should be able to build, release, operate, recover, and audit representative applications at least as safely as before. The decision to replace rather than keep building needs a clear economic basis. [Build vs buy an internal developer platform](https://northflank.com/blog/build-vs-buy-an-internal-developer-platform) explains when owning the platform remains strategic and when buying and extending the execution layer is the stronger use of platform engineering capacity. ## What should you preserve when replacing a DIY internal developer platform? Where possible, preserve the developer-facing contract: the workflows, interfaces, and delivery outcomes that teams depend on. You do not need to preserve every implementation detail of the DIY platform. For each workload type, record what developers and automated clients depend on: the repository event that starts a build, the workload definition, required inputs, environment names, promotion process, URLs, access rules, logs, alerts, rollback action, and support owner. Treat undocumented behavior as a migration risk, even when it appears convenient. Then baseline build and deployment success, lead time, rollback time, recovery time, failed-change rate, ticket volume, queue time, and platform and infrastructure cost by workload cohort. These thresholds show whether the replacement improves delivery or merely changes its interface. If different teams need different entry points, Northflank exposes the application platform through its UI, [API and CLI](https://northflank.com/docs/v1/api/introduction), and [templates managed with GitOps](https://northflank.com/docs/v1/application/infrastructure-as-code/gitops-on-northflank). This lets you migrate the underlying build, deployment, and environment workflows first, while updating a custom portal, CLI wrapper, or repository workflow separately. ## How do you replace a DIY internal developer platform in phases? A lower-risk replacement uses phased coexistence, with an acceptance test, rollback, and owner for each stage. ### 1. Inventory the delivery path and establish a baseline Trace a deployment from commit through build, registry, environment creation, configuration, release, routing, telemetry, and recovery. Include scheduled jobs and operator actions, not only long-running services. Map each component to an owner and dependent workload. Record which system controls configuration and production changes so two platforms cannot write competing state. ### 2. Define the target workload patterns and platform controls Define supported workload patterns based on real use cases, such as an HTTP service, worker, scheduled job, service with a database, and full-stack preview environment. Specify the developer inputs and platform controls for each. For each workload pattern, define resource defaults, health checks, domains, secrets, private dependencies, logs, scaling, backup expectations, promotion, and rollback. Keep an escape path for requirements that the standard pattern cannot express, but give it an owner and review process so exceptions do not recreate the DIY platform inside the replacement. If your platform team wants those patterns to be repeatable and reviewable, Northflank uses [infrastructure as code templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code) for services, databases, integrations, workflows, release flows, and preview environments. Templates can be managed in Git and parameterized for different projects, environments, regions, or cloud targets. ### 3. Reproduce one representative workload Choose a representative, reversible workload with active maintainers and regular releases. A static demo tests too little; the highest-risk revenue service creates unnecessary exposure. Reproduce its delivery path. Compare the artifact, configuration, network access, data behavior, health signals, scaling, and recovery. For branch-level validation, Northflank [preview environments](https://northflank.com/product/preview-environments) can create ephemeral full-stack environments containing services, jobs, and databases. This gives developers and platform engineers somewhere to test the target workload patterns and platform configuration before any production route changes. ### 4. Run old and new delivery paths in parallel Parallel operation reduces cutover risk only when authority is unambiguous. Select one source of truth for each configuration and prevent both platforms from independently promoting or mutating the same production workload. Build once and promote the same immutable artifact where practical. Compare health, logs, resources, latency, and dependencies. Shift limited traffic only after non-production behavior matches, and keep routing rollback outside the component under test. If releases need sequenced checks, Northflank [workflows](https://northflank.com/docs/v1/application/release/configure-workflows) can connect builds, deployments, jobs, backups, conditions, and manual approval steps. This separates the decision to release an application from the wider decision to expand the platform migration. ### 5. Migrate workloads by risk cohort Group workloads by criticality, statefulness, private dependencies, compliance scope, release frequency, and rollback difficulty. Move one cohort at a time, then observe releases, incidents, on-call events, and scheduled operations. Start with representative, reversible services. Continue with common stateless patterns, then stateful or privately connected workloads, and leave exceptional or tightly regulated systems until the relevant controls and recovery paths have been demonstrated. ### 6. Remove old write paths and retire the DIY platform Decommissioning begins by stopping new dependencies, not by deleting infrastructure. Freeze new features on the DIY platform, remove its production mutation rights, revoke unused service credentials, and route remaining requests to the supported path. Keep an observation window that includes month-end jobs, certificate renewal, restore tests, access reviews, and infrequent releases. Archive required configuration, audit history, runbooks, dependencies, and recovery decisions before removing old resources. ## How should you migrate stateful services, networking, and secrets when replacing a DIY platform? Treat stateful services, networking, and secrets as separate migrations with their own rollback because they can outlive or bypass the application deployment path. For databases, decide whether the platform will manage the existing service, provision a replacement, or connect to an external system. Test backup and restore before cutover. Keep application versions compatible with both sides of the transition, and avoid irreversible schema changes while rollback still depends on the old environment. For networking, inventory domains, private APIs, service discovery, egress allowlists, webhooks, certificates, and DNS time to live. Test from the target runtime. A service that cannot reach a private dependency has not migrated. For secrets, map consumers and scopes, create the target references, rotate values where exposure or duplication warrants it, and revoke the old delivery path after cutover. Do not solve migration speed by copying broad production credentials into both platforms indefinitely. If your enterprise must preserve its cloud account, VPC, private routes, or existing infrastructure commitments, Northflank [BYOC](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements) provisions and manages a new Kubernetes cluster in your cloud account. Workloads remain within your cloud and network boundary. If you need to import a compatible existing Kubernetes cluster, Northflank provides a separate BYOK option. External cloud resources can also be coordinated with configuration through [OpenTofu nodes in Northflank templates](https://northflank.com/docs/v1/application/infrastructure-as-code/external-infrastructure). ## What evidence shows a DIY platform replacement is ready to expand? A replacement is generally ready to expand when it repeatedly meets delivery, runtime, recovery, governance, adoption, and cost criteria under real workload conditions. - Delivery: builds and releases complete reliably, with acceptable lead time and queue behavior. - Runtime: health checks, scaling, networking, persistence, logs, and alerts behave as expected. - Recovery: rollback, backup restore, credential revocation, and incident procedures work without relying on undocumented access. - Governance: access is scoped, production changes are attributable, and required approvals and evidence exist. - Adoption: developers can complete common tasks without platform-team intervention or side channels. - Cost: usage is attributable by team or workload, and parallel infrastructure has a defined end date. Use explicit gates for each cohort. One successful release is not enough to approve the next workload cohort. Evidence should include routine operation and failure tests, not only the happy path. Northflank [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) capture platform events, while [Northflank for Enterprise](https://northflank.com/enterprise) adds identity and governance capabilities. Application logs and business-level release evidence remain separate responsibilities. ## How can Northflank support a DIY internal developer platform replacement? Northflank provides [composable internal developer platform capabilities](https://northflank.com/product/idp) for build, deployment, runtime, environment, and release workflows. These capabilities include [infrastructure as code templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code), [Git-based builds, services, jobs, and stateful services](https://northflank.com/features/platform), [full-stack preview environments](https://northflank.com/product/preview-environments), and [release workflows](https://northflank.com/docs/v1/application/release/configure-workflows). During migration, teams can use [logs, metrics, and health monitoring](https://northflank.com/docs/v1/application/observe/monitor-containers) to validate each workload cohort. Northflank can also connect with the surrounding toolchain through [platform integrations](https://northflank.com/features/platform) for version control systems and container registries, log forwarding and metrics export, external DNS and CDN providers, and existing CI/CD systems. Run workloads on managed [Northflank Cloud](https://northflank.com/features/managed-cloud) infrastructure, or use [BYOC](https://northflank.com/product/bring-your-own-cloud) when network boundaries, regional placement, capacity, or commitments require them to remain in your cloud account. Apply templates and configuration across preview, staging, and production. As migration expands, [enterprise controls](https://northflank.com/enterprise) provide SSO, directory synchronization, RBAC, scoped API access, template review, and platform audit logs. Northflank is [SOC 2 Type 2 and HIPAA compliant](https://northflank.com/security), with BAAs available under Enterprise contracts. These controls govern platform access, while applications remain responsible for access to business data and actions. For teams using coding agents, [Northflank Skills](https://github.com/northflank/skills) guide deployment, operations, and automation with tools such as Codex, Claude Code, Cursor, OpenCode, and Windsurf. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your platform replacement requirements. ## Frequently asked questions about replacing a DIY internal developer platform ### Do you need to replace your developer portal too? Not necessarily. Northflank's [API, CLI, GitOps, and templates](https://northflank.com/features/platform) can integrate with an existing portal, so teams can retain a useful catalog or interface and update it separately. ### Which workload should you migrate first? Neither extreme is ideal. Start with a representative workload that changes regularly, has engaged owners, tests platform capabilities, and can be rolled back safely. Use the results to define the first cohort. ### Do old and new platforms need to run in parallel? It depends on the workload, but plan a bounded coexistence period. The platforms need enough overlap to validate delivery, shift traffic safely, and preserve rollback, but they do not need to operate every workload simultaneously. ### When can you decommission the DIY platform? Decommission after verifying that no supported workload depends on the DIY platform, production write access is removed, rollback no longer requires it, infrequent operations have run, and required configuration, audit history, runbooks, and recovery records are archived. ## Related articles about internal developer platforms - [Build vs buy an internal developer platform: costs, trade-offs, and ROI](https://northflank.com/blog/build-vs-buy-an-internal-developer-platform) - [How to build an internal developer platform (and why you might not want to)](https://northflank.com/blog/how-to-build-an-internal-developer-platform) - [Top 6 internal developer platforms](https://northflank.com/blog/top-six-internal-developer-platforms) - [The future of the AI-native internal developer platform and the AI SDLC](https://northflank.com/blog/ai-sdlc) - [Vercel-like developer experience for on-premises deployments](https://northflank.com/blog/vercel-like-developer-experience-for-on-premises-deployments)

Northflank vs Modal Sandboxes: which platform fits your requirements?

2026-08-31T16:59:00.000Z

Northflank and Modal Sandboxes both provide isolated CPU and GPU environments for running code and AI workloads, but they use different application and infrastructure models. Modal offers code-first sandbox execution within its managed serverless AI platform, while Northflank provides production-grade secure sandboxes using Kata Containers with Cloud Hypervisor as its primary microVM approach, with Firecracker and gVisor where supported and appropriate. Northflank also runs the surrounding application stack, including APIs, workers, jobs, managed data, preview environments, and workflows. The decision is whether to define sandbox execution through application code on managed infrastructure or operate it with the production architecture through one control plane. This comparison covers lifecycle, isolation, persistence, startup and scaling, GPUs, networking, developer experience, infrastructure control, data residency, pricing, and operations. ## TL;DR: Northflank vs Modal Sandboxes Modal Sandboxes fit code-first serverless execution within Modal's managed AI platform, while Northflank fits teams that need secure sandboxes alongside production applications and customer-controlled infrastructure in one control plane. - **Modal Sandboxes fit teams that need code-first serverless execution.** Python and Beta JavaScript/TypeScript and Go SDKs create gVisor-isolated CPU or GPU environments from Modal Images. - **Northflank fits teams that need production-grade isolated CPU or GPU execution and the complete architecture supporting it.** It combines Kata Containers with Cloud Hypervisor, plus Firecracker and gVisor where supported and appropriate, with services, workers, jobs, managed data, persistent volumes, automatic full-stack previews, workflows, and no fixed sandbox-session duration. - **Their infrastructure boundaries differ.** Modal uses managed multi-cloud capacity with region pinning. Northflank supports Northflank Cloud, self-service BYOC, and eligible BYOK, including on-premises and bare metal. - **Their pricing models reflect different product boundaries.** Modal offers Starter with included compute, Team at $250 per month plus usage, and custom Enterprise pricing. Northflank offers an always-on free Sandbox tier, self-service Pay-as-you-go without seat fees, and custom Enterprise plans. Northflank BYOC combines platform fees with direct cloud-provider billing. **If your team or organisation needs isolated CPU or GPU execution alongside its production services, Northflank provides one control plane for the architecture.** Developers get governed self-service while platform teams control networking, security, observability, clusters, and deployment targets across [Northflank Cloud](https://northflank.com/features/managed-cloud), production [BYOC](https://northflank.com/features/bring-your-own-cloud), or eligible [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements). Northflank has supported self-service production BYOC since 2019. [Northflank Skills](https://github.com/northflank/skills) help Codex, Claude Code, Cursor, and compatible agents deploy and troubleshoot through the API and CLI. Agents authenticate with API tokens, inherit the token's RBAC permissions, and have their API or CLI actions recorded in audit logs. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## Northflank vs Modal Sandboxes comparison table The key differences are platform scope, lifecycle, interfaces, and infrastructure ownership. | Requirement | Northflank | Modal Sandboxes | | --- | --- | --- | | Best for | Enterprises, platform teams, AI engineering teams, and startups that need production-grade CPU or GPU sandboxes, complete application stacks, governed developer self-service, and control over cloud or Kubernetes infrastructure | AI engineering, machine learning, and application development teams that need code-first CPU or GPU sandboxes alongside serverless Functions, batch jobs, inference, and training on Modal-managed multi-cloud infrastructure | | Product scope | Production-grade isolated CPU and GPU sandboxes plus services, workers, jobs, managed databases and queues, volumes, workflows, automatic full-stack previews, and supporting infrastructure | Code-first sandboxes within managed serverless AI compute for Functions, jobs, inference, and training | | Isolation | Kata Containers with Cloud Hypervisor, plus Firecracker and gVisor where supported; BYOC availability depends on its configuration; Cloud GPUs use gVisor by default | gVisor for standard Sandboxes; Beta full-VM runtime with a conventional Linux kernel | | Lifecycle | Scale to zero, scale back up, restart, or delete; attached volumes and service configuration persist; no fixed sandbox-session duration | Five-minute default timeout and 24-hour maximum per Sandbox; idle timeout and explicit termination are also supported | | Environment creation | Git, Dockerfiles, Buildpacks, images, Templates, API, CLI, volumes, backups, and clones | Modal Images defined in code, from Dockerfiles, or from registries | | Compute and GPUs | 0.1–32 vCPU, 256 MB–256 GB memory, GPU plans, scaling, and custom BYOC node pools | Burstable CPU and memory plus GPU Sandboxes on the standard runtime; Beta V2 and VM Sandboxes do not currently support GPUs | | Persistence | Ephemeral root with persistent volumes across restarts and scale-to-zero; volume backups and clones support reuse | Filesystem and directory snapshots, Alpha memory snapshots, Modal Volumes, and cloud bucket mounts | | Networking | Private discovery, public and private ports, network policies, multi-project access, static egress, and BYOC VPC routing | Outbound blocking, CIDR allowlists, Beta domain allowlists, tunnels, connect tokens, and same-region private networking on V2 | | Interfaces | UI, API, CLI, JavaScript client, Git, images, Templates, GitOps, Workflows, and Skills for coding agents | Python-first SDK plus Beta JavaScript/TypeScript and Go SDKs and CLI tooling | | Supporting workloads | Services, workers, jobs, managed data, previews, workflows, and GPUs | Functions, batch jobs, inference, training, Notebooks, storage, and GPUs | | Preview environments | Preview Blueprints automate full-stack applications, data, jobs, volumes, networking, seed workflows, and URLs | No native support for automatic full-stack preview environments | | Infrastructure | Northflank Cloud, self-service BYOC since 2019, and eligible cloud, on-premises, or bare-metal BYOK | Modal-managed AWS, GCP, and OCI capacity with region selection | | Observability and governance | Logs, metrics, health checks, alerts, audit logs, log sinks, RBAC, scoped access, directory integrations, policies, and cluster context | Sandbox logs and metrics, paid-plan RBAC, and Enterprise workspace audit logs | | Pricing | Always-on free Sandbox tier; self-service Pay-as-you-go with per-second compute and no seat fees; custom Enterprise; BYOC platform fees with direct cloud-provider billing | Starter with included compute; Team at $250 per month plus usage with included compute; custom Enterprise; per-second CPU, memory, and GPU charges | | Operations | Northflank operates its managed cloud, provisions and manages BYOC clusters, and manages the Northflank platform on BYOK clusters | Modal operates its managed platform and underlying multi-cloud infrastructure | ## Who are Northflank and Modal Sandboxes designed for? Modal serves AI engineering, machine learning, and application development teams that prefer code-first isolated CPU or GPU execution on managed serverless infrastructure. Developers configure Modal Sandboxes through Python or the Beta JavaScript/TypeScript and Go SDKs, including images, compute resources, networking, timeouts, and persistence. Modal Sandboxes operate alongside Modal Functions, endpoints, batch jobs, inference, training, Notebooks, Queues, Volumes, and cloud bucket mounts. Standard Modal Sandboxes use gVisor and run on Modal-managed multi-cloud infrastructure with optional region selection. Northflank serves enterprises, platform organisations, AI teams, and startups that need secure [sandboxes](https://northflank.com/product/sandboxes) and supporting production workloads under one deployment, networking, governance, and observability model. Compatible images can run as sandboxes, APIs, persistent workers, or [jobs](https://northflank.com/create-trigger-and-schedule-jobs-and-cron-jobs) with [persistent volumes](https://northflank.com/docs/v1/application/databases-and-persistence/add-a-volume) and CPU or [GPU resources](https://northflank.com/docs/v1/application/gpu-workloads/gpus-on-northflank). Managed databases, queues, and object storage share the same control plane. For isolation, Northflank uses [Kata Containers](https://northflank.com/blog/what-are-kata-containers) with [Cloud Hypervisor](https://northflank.com/blog/guide-to-cloud-hypervisor) as its primary microVM approach, with [Firecracker](https://northflank.com/blog/what-is-aws-firecracker) and [gVisor](https://northflank.com/blog/what-is-gvisor) where supported and appropriate. In [BYOC](https://northflank.com/features/bring-your-own-cloud), runtime availability depends on the provider, region, and node-pool configuration, while Northflank Cloud GPU workloads use gVisor by default. ## How do Northflank and Modal Sandboxes compare on lifecycle and persistence? Each Modal Sandbox runs for five minutes by default and can be configured for a maximum lifetime of 24 hours. An idle timeout can end inactive sessions earlier. Applications can continue by creating replacement Sandboxes and restoring persisted state, but commands cannot run inside a Sandbox after it finishes. Modal filesystem and directory snapshots default to 30-day retention but can use another retention period or no expiry. Alpha memory snapshots expire after seven days and terminate the source Sandbox. Volumes provide shared storage, while cloud bucket mounts connect to S3, Cloudflare R2, or Google Cloud Storage. [Northflank sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) use a service lifecycle rather than a time-boxed session. Teams can execute commands, expose ports, restart, scale to zero, scale back up, or delete them through several interfaces. Northflank does not impose a fixed sandbox-session duration. Northflank's root filesystem is ephemeral, while [persistent volumes](https://northflank.com/docs/v1/application/databases-and-persistence/add-a-volume) preserve repositories, datasets, models, notebooks, and agent state across restarts and scale-to-zero. Scaling back up starts new compute and reattaches the volume; it does not preserve RAM or running processes. Templates and Workflows can reproduce the surrounding application topology. ## How do Northflank and Modal Sandboxes compare on environments, startup, and scale? Modal Images use Python definitions, Dockerfile commands, or registry images. Modal containers boot in about one second, although initialization can extend the time until a container is ready; teams can keep initialized Sandboxes warm when latency is critical. Modal's V2 Sandbox backend is in Beta and recommended above 20 creates per second or 10,000 concurrent Sandboxes. It currently has a separate feature matrix and does not yet support GPUs. Northflank accepts images or Git builds using [Dockerfiles](https://northflank.com/docs/v1/application/build/build-with-a-dockerfile) and [Buildpacks](https://northflank.com/docs/v1/application/build/build-with-buildpacks). Northflank's microVM-backed sandboxes boot in under one second. [Templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code), [horizontal autoscaling](https://northflank.com/docs/v1/application/scale/autoscale-deployments), scale-to-zero, and BYOC node-pool controls manage topology and capacity. In the [ComputeSDK 2026 Scale Invitational](https://platform.computesdk.com/scale-invitational), Northflank reached 100,000 concurrent sandboxes in 24 seconds, compared with 32 seconds for Modal. Northflank used 0.5-CPU sandboxes, while Modal used 0.125-CPU burst sandboxes, so the result demonstrates fleet-scaling performance under the tested configurations rather than a controlled per-sandbox comparison. ## Which compute and GPU workloads do Northflank and Modal Sandboxes support? Modal Sandboxes request physical CPU cores and memory, can burst when capacity exists, and support upper limits. Standard Sandboxes can request NVIDIA GPUs but are subject to preemption. Modal's Beta VM Sandboxes currently support CPU workloads only, and the V2 Beta backend does not yet support GPUs. Northflank runs compatible images as isolated sandboxes, persistent services and workers, or one-off, scheduled, and API-triggered jobs. [GPU-backed sandboxes, model-serving services, and jobs](https://northflank.com/docs/v1/application/gpu-workloads/gpus-on-northflank) can run in [GPU-enabled Northflank Cloud regions](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-on-northflank-cloud) or on [compatible BYOC node pools](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud). If an agent needs isolated execution and persistent GPU inference, Northflank can place the sandbox, model endpoint, API, queue, database, and workers in one control plane. Teams can separate CPU and GPU pools and apply placement rules. ## How do Northflank and Modal Sandboxes compare on networking, security, and observability? Standard Modal Sandboxes run on gVisor. By default, they cannot accept inbound traffic or access other workspace resources. Outbound access can be blocked or restricted by CIDR; domain allowlists are Beta and live policy changes are Alpha. Tunnels and connect tokens expose applications. Beta Modal VM Sandboxes provide a conventional Linux kernel. Sandbox output and resource data appear in logs and metrics. Team and Enterprise plans add RBAC; Enterprise audit logs cover control-plane changes rather than individual `exec` commands. Northflank uses [Kata Containers](https://northflank.com/blog/what-are-kata-containers) with [Cloud Hypervisor](https://northflank.com/blog/guide-to-cloud-hypervisor) as its primary microVM approach, with [Firecracker](https://northflank.com/blog/what-is-aws-firecracker) and [gVisor](https://northflank.com/blog/what-is-gvisor) where supported and appropriate. In BYOC, runtime availability and selection depend on the provider, region, and node-pool configuration. Northflank Cloud GPU workloads use gVisor by default. [Private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank) connects Northflank sandboxes with internal services. Teams can add [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies), multi-project access, public ports, and configurable egress. [Logs and metrics](https://northflank.com/docs/v1/application/observe/observability-on-northflank), health checks, alerts, audit logs, log sinks, and BYOC monitoring span the stack. ## How do Northflank and Modal Sandboxes compare on developer experience? Modal provides a code-first workflow, while Northflank combines governed developer self-service with platform automation across the sandbox and its supporting stack. Python is Modal's primary language. Its Beta JavaScript/TypeScript and Go SDKs also create Sandboxes, run commands, manage files, and expose ports. Northflank supports [Dockerfiles](https://northflank.com/docs/v1/application/build/build-with-a-dockerfile), [Buildpacks](https://northflank.com/docs/v1/application/build/build-with-buildpacks), [Workflows](https://northflank.com/docs/v1/application/release/configure-workflows), [Templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code), [GitOps](https://northflank.com/docs/v1/application/infrastructure-as-code/gitops-on-northflank), [API](https://northflank.com/docs/v1/api/use-the-api), [CLI](https://northflank.com/docs/v1/api/use-the-cli), and a [JavaScript client](https://northflank.com/docs/v1/api/use-the-javascript-client). [Skills for coding agents](https://github.com/northflank/skills) help compatible agents deploy and troubleshoot through the API and CLI. Agents authenticate with API tokens, inherit the token's RBAC permissions, and have their API or CLI actions recorded in audit logs. [Northflank Preview Blueprints](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) automatically create full-stack branch or pull-request environments with applications, data, jobs, volumes, networking, seed workflows, and URLs. Modal provides Functions, endpoints, storage, Queues, and batch execution that developers can assemble around a Sandbox. ## How do infrastructure control and data residency differ? Modal runs its public Sandbox service on managed AWS, GCP, and OCI infrastructure with optional region selection. Northflank offers Northflank Cloud; self-service production BYOC across AWS, GCP, Azure, Oracle Cloud, Civo, CoreWeave, and Nebius; and eligible BYOK for public-cloud, on-premises, or bare-metal Kubernetes clusters. Broad or narrow Modal region pinning adds a 1.5x or 1.75x multiplier. Data-plane requests go to the selected region, lifecycle requests use Modal's US-east control plane, and Modal-managed logs, storage, Secrets, Queues, and snapshots remain in the United States. [Northflank Cloud](https://northflank.com/features/managed-cloud) provides the managed path. With production [BYOC](https://northflank.com/features/bring-your-own-cloud), workloads run in the customer's account and VPC while Northflank manages the platform layer. The customer retains the account, network, capacity choices, policies, and cloud bill. Northflank has supported self-service production BYOC since 2019. Eligible [Northflank BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements) connects cloud, on-premises, or bare-metal Kubernetes. BYOC requires at least one node and BYOK three, with at least 12 vCPU and 24 GB per cluster. ## How do Northflank and Modal Sandboxes compare on pricing? Modal uses Sandbox-specific rates; Northflank uses Cloud compute rates or BYOC platform plus infrastructure billing. - **Modal Sandboxes:** Modal's Starter plan has no platform fee and includes $30 of monthly compute. Team costs $250 per month plus usage and includes $100 of monthly compute; Enterprise is custom. CPU costs $0.1419 per physical core-hour, with one physical core equivalent to 2 vCPUs. Memory costs $0.0240 per GiB-hour. Billing uses the higher of requested or actual usage, while region pinning and non-preemptible execution add multipliers. - **Northflank:** Northflank offers an always-on free Sandbox tier, self-service Pay-as-you-go, and custom Enterprise plans. The free tier includes two services, one database, and two cron jobs. [Northflank Cloud pricing](https://northflank.com/pricing) is billed per second without Pay-as-you-go seat fees, starting at $0.01667 per vCPU-hour and $0.00833 per GB-hour. Persistent storage costs $0.15 per GB-month, and network egress costs $0.06 per GB. In BYOC, Northflank charges platform fees while the cloud provider bills infrastructure directly. Compare total workload costs, including storage, transfer, GPUs, plan fees, and supporting services. ## When do Modal Sandboxes fit your requirements? Modal Sandboxes fit teams that want serverless isolated execution expressed through application code and operated on Modal-managed infrastructure. - Your application uses Modal Functions, inference, training, batch jobs, Notebooks, or storage. - Python-first definitions and programmatic Sandbox creation match the team's workflow. - A 24-hour per-Sandbox maximum works with replacement Sandboxes backed by filesystem snapshots, Volumes, or cloud bucket mounts. - gVisor, network controls, burstable CPU or GPU resources, and Modal-managed infrastructure fit; Beta V2 supports high creation rates or concurrency. ## When does Northflank fit your requirements? Northflank fits teams that need production-grade isolated CPU or GPU sandboxes alongside the supporting application stack, with control over deployment location, networking, Kubernetes infrastructure, security, and observability. - Sandboxes need no fixed session limit and must run beside persistent services, workers, jobs, and data. - Automatic previews must reproduce applications, data, networking, and seed workflows. - Developers need self-service while platform teams control networking, resources, node pools, policies, and deployment location. - Self-service production BYOC, eligible BYOK, or direct cloud-provider billing is required. ## Northflank vs Modal Sandboxes: final decision Modal fits teams that want code-first sandbox and AI-compute workloads on Modal-managed serverless infrastructure. Northflank fits teams building production architectures in which secure CPU or GPU sandboxes, APIs, workers, jobs, managed data, private networking, previews, observability, and customer-controlled infrastructure operate as one governed system. Choose based on the operating model: Modal for application-defined serverless compute on a managed platform, or Northflank for one control plane spanning isolated execution and the production architecture. **Run secure sandboxes and their supporting production architecture on Northflank.** Kata Containers with Cloud Hypervisor is the primary microVM approach, with Firecracker and gVisor where supported and appropriate. One control plane spans applications, data, workflows, previews, and CPU or GPU workloads across Northflank Cloud, production BYOC, or eligible BYOK. Northflank has supported self-service production BYOC since 2019. [Northflank Skills](https://github.com/northflank/skills) help compatible coding agents deploy and troubleshoot through the API and CLI. Agents authenticate with API tokens, inherit the token's RBAC permissions, and have their API or CLI actions recorded in audit logs. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## Frequently asked questions about Northflank vs Modal Sandboxes These answers summarise the main differences. ### What is the main difference between Northflank and Modal Sandboxes? Both provide isolated CPU and GPU execution. Modal delivers it through a code-first serverless AI platform on Modal-managed infrastructure. Northflank delivers production-grade sandboxes through an application and infrastructure control plane that also runs services, workers, jobs, managed data, previews, and customer-cloud deployments. ### Is Northflank a Modal Sandboxes alternative? Yes. Northflank provides programmatically controlled, isolated CPU or GPU sandboxes and also runs the APIs, workers, jobs, managed data, networking, previews, and infrastructure supporting them. ### Is Northflank or Modal better for AI-agent sandboxes? Modal fits agents beside other Modal AI workloads. Northflank fits agents sharing production networking, data, governance, or customer-cloud infrastructure. ### How do Northflank and Modal Sandboxes preserve state? Modal uses filesystem and directory snapshots, Volumes, and bucket mounts; memory snapshots are Alpha. Northflank volumes preserve data across restarts and scale-to-zero, while Templates and Workflows reproduce the surrounding topology. ### Can Modal Sandboxes run in your own cloud account? No. Modal Sandboxes run on Modal-managed multi-cloud infrastructure with optional region selection. Northflank offers self-service BYOC for customer cloud accounts and eligible BYOK for existing Kubernetes infrastructure ### Do Northflank and Modal Sandboxes support GPUs? Yes. Northflank supports GPU sandboxes in GPU-enabled Northflank Cloud regions and on compatible BYOC GPU node pools. Modal supports GPU sandboxes on its standard runtime, but its V2 Beta backend does not yet support GPUs and its Beta VM Sandboxes currently support CPU workloads only. ### How do Northflank and Modal Sandboxes isolate code execution? Standard Modal Sandboxes use gVisor; Beta VM Sandboxes provide a conventional Linux kernel. Northflank uses Kata Containers with Cloud Hypervisor as its primary microVM approach, with Firecracker and gVisor where supported and appropriate. ### Is Northflank or Modal Sandboxes cheaper? Modal can fit intermittent serverless execution, but plan fees, physical-core pricing, GPUs, and regional multipliers affect cost. Northflank combines a free Sandbox tier, Pay-as-you-go without seat fees, and Enterprise plans with per-second Cloud compute or direct BYOC infrastructure billing.

Northflank vs E2B Sandboxes: which platform fits your requirements?

2026-08-31T16:56:00.000Z

Northflank and E2B Sandboxes both provide isolated code execution but solve different-sized infrastructure problems. E2B packages Firecracker microVMs as an SDK-first sandbox product, while Northflank provides secure sandboxes using Kata Containers with Cloud Hypervisor as its primary microVM approach, with Firecracker and gVisor where supported and appropriate. Northflank also runs the surrounding application stack, including APIs, workers, jobs, managed data, preview environments, workflows, and CPU or GPU workloads. The decision is whether you need a standalone sandbox SDK or one control plane for the production architecture. This comparison covers lifecycle, isolation, persistence, networking, GPUs, BYOC, BYOK, security, observability, pricing, and operations. ## TL;DR: Northflank vs E2B Sandboxes E2B is a standalone, SDK-first sandbox product. Northflank runs isolated sandboxes and their supporting production infrastructure. - **E2B fits teams that want an SDK-first AI-agent sandbox.** Its JavaScript/TypeScript and Python libraries create Firecracker microVMs, execute code, manage files, expose ports, and pause or resume state. - **Northflank fits teams that need production-grade isolated CPU or GPU execution and the complete architecture supporting it.** It uses Kata Containers with Cloud Hypervisor as its primary microVM approach, with Firecracker and gVisor applied where supported and appropriate. The same platform runs services, workers, jobs, managed data, persistent volumes, automatic full-stack previews, and workflows without a fixed sandbox-session duration. - **Session models differ.** E2B limits continuous runtime to one hour on Hobby and 24 hours on Pro, with custom Enterprise limits. Northflank does not impose a fixed sandbox-session duration. - **Customer-cloud models differ.** E2B provides AWS and GCP BYOC through Enterprise, not public self-service. Northflank has supported [self-service production BYOC since 2019](https://northflank.com/features/bring-your-own-cloud) across [AWS](https://northflank.com/cloud/aws), [GCP](https://northflank.com/cloud/gcp), [Azure](https://northflank.com/cloud/azure), and other supported clouds, plus eligible [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements). - **Pricing models differ.** E2B offers free Hobby, $150-per-month Pro, and custom Enterprise plans, plus per-second usage. Northflank offers an always-on free Sandbox tier, per-second Pay-as-you-go Cloud without seat fees, and custom Enterprise. BYOC combines Northflank platform fees with direct cloud-provider billing. If your team needs isolated execution alongside APIs, workers, jobs, data, previews, volumes, or GPUs, [Northflank sandboxes](https://northflank.com/product/sandboxes) bring the stack into one control plane. Developers get Kubernetes-free self-service while platform teams retain governance and infrastructure control across [Northflank Cloud](https://northflank.com/features/managed-cloud), production [BYOC](https://northflank.com/features/bring-your-own-cloud), or eligible [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements). Northflank has supported self-service production BYOC since 2019. [Northflank Skills](https://github.com/northflank/skills) help Codex, Claude Code, Cursor, and compatible agents deploy and troubleshoot through the API and CLI, subject to credentials, RBAC, and audit controls. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your requirements. ## Northflank vs E2B Sandboxes comparison Both platforms provide isolated execution. E2B delivers it as a standalone sandbox SDK and service, while Northflank combines secure sandboxes with complete application and infrastructure management. | Requirement | Northflank | E2B Sandboxes | | --- | --- | --- | | Best for | Enterprises, platform teams, AI engineering teams, and startups that need production-grade CPU or GPU sandboxes, complete application stacks, governed developer self-service, and control over cloud or Kubernetes infrastructure | AI engineers and developers who want an SDK-first Firecracker sandbox service for agent-generated code, code interpreters, evaluations, data analysis, and user-submitted code | | Product scope | Production-grade isolated sandboxes plus services, workers, jobs, managed databases and queues, volumes, workflows, preview environments, and CPU or GPU workloads in one control plane | Standalone sandbox service with SDKs, API, CLI, templates, and agent integrations | | Isolation | Kata Containers with Cloud Hypervisor as the primary microVM approach, with Firecracker and gVisor applied where supported and appropriate; in BYOC, availability and selection depend on provider, region, and node-pool configuration; Northflank Cloud GPU workloads use gVisor by default | Firecracker microVM per sandbox | | Lifecycle | Under-one-second sandbox boot; ephemeral or long-running services with create, scale to zero, scale back up, restart, and destroy controls; no fixed sandbox-session duration | Five-minute default timeout; one-hour Hobby and 24-hour Pro runtime limits; pause/resume; custom Enterprise limits | | Environment creation | Git, Dockerfiles, Buildpacks, images, Templates, API, CLI, and volumes | Prebooted Dockerfile or SDK templates; snapshots and forks | | Resources | 0.1–32 vCPU and 256 MB–256 GB on Northflank Cloud; custom plans and CPU/GPU node pools in BYOC | Default 2 vCPU/512 MiB; up to 8 vCPU and 8 GiB RAM; 10 GiB Hobby or 20 GiB Pro disk; larger custom configurations | | GPU | GPU-backed sandboxes, model-serving services, and jobs on supported infrastructure | Public managed offering does not include GPU sandboxes | | Filesystem | Ephemeral sandbox root filesystem; persistent volumes preserve repositories, datasets, models, or agent state across restarts and scale-to-zero | Pause preserves filesystem and memory by default, with filesystem-only pause available; snapshots and forks support reusable state | | Networking | Full-stack private networking and discovery; public/private ports, network policies, multi-project connectivity, static egress, and BYOC VPC routing | Internet by default, allow/deny egress rules, and public port URLs | | Automation | UI, API, CLI, JavaScript client, Templates, GitOps, Workflows, and Skills for coding agents | JavaScript/TypeScript and Python SDKs, REST API, CLI, Code Interpreter, and agent integrations | | Supporting stack | Services, workers, jobs, managed data, volumes, workflows, and CPU/GPU workloads | Sandbox compute; application, data, queue, and model-serving infrastructure remains separate | | Preview environments | Automated full-stack Preview Blueprints with applications, data, jobs, volumes, networking, seed workflows, and URLs | Temporary applications without managed full-stack orchestration | | Infrastructure | Northflank Cloud; self-service production multi-cloud BYOC since 2019; eligible cloud, on-premises, and bare-metal BYOK | E2B Cloud; AWS and GCP BYOC available only through Enterprise, not self-service; open-source self-hosting | | Observability | Workload logs and metrics, health checks, alerts, audit logs, log sinks, and BYOC cluster monitoring | Logs, resource metrics, lifecycle events, webhooks, and best-effort OpenTelemetry export | | Security and enterprise | Governed developer self-service with RBAC, SSO, directory sync, audit logs, scoped API access, policies, customer-VPC options, SLAs, 24/7 support, and FDE onboarding | Firecracker isolation, sandbox-traffic access tokens, and configurable network restrictions; RBAC is not yet available | | Pricing | Always-on free Sandbox tier; pay-as-you-go Northflank Cloud billed per second with no seat fees; custom Enterprise; BYOC platform fees with infrastructure billed directly by the cloud provider | Free Hobby plus usage and $100 one-time credit; Pro at $150/month plus usage; custom Enterprise | | Operations | Northflank operates its cloud and platform; infrastructure duties differ across BYOC and BYOK | E2B operates its hosted service; Enterprise agreements define the BYOC responsibility split, while self-hosting transfers platform operations to the user | ## Who are Northflank and E2B Sandboxes designed for? E2B serves developers embedding isolated Linux environments into agents or applications through JavaScript/TypeScript or Python SDKs. Use cases include generated or user-submitted code, analysis, computer use, evaluations, and code interpreters. Templates, snapshots, forks, and pause/resume support reuse; the surrounding production stack remains separate. Northflank serves enterprises, platform organisations, AI teams, and startups that need [sandboxes](https://northflank.com/product/sandboxes) inside a production architecture. Compatible images can run as isolated sandboxes, APIs, persistent workers, or [one-off, scheduled, and API-triggered jobs](https://northflank.com/create-trigger-and-schedule-jobs-and-cron-jobs) with ports, [persistent volumes](https://northflank.com/docs/v1/application/databases-and-persistence/add-a-volume), and CPU or [GPU resources](https://northflank.com/docs/v1/application/gpu-workloads/gpus-on-northflank). [Managed databases](https://northflank.com/docs/v1/application/databases-and-persistence/deploy-a-database), caches, [queues](https://northflank.com/docs/v1/application/databases-and-persistence/configure-addons-for-high-availability), and [object storage](https://northflank.com/dbaas/managed-minio) share the same control plane. For isolation, Northflank uses [Kata Containers](https://northflank.com/blog/what-are-kata-containers) with [Cloud Hypervisor](https://northflank.com/blog/guide-to-cloud-hypervisor) as its primary microVM approach, with [Firecracker](https://northflank.com/blog/what-is-aws-firecracker) and [gVisor](https://northflank.com/blog/what-is-gvisor) where supported and appropriate. In [BYOC](https://northflank.com/features/bring-your-own-cloud), runtime availability depends on the provider, region, and node-pool configuration, while Northflank Cloud GPU workloads use gVisor by default. ## How do Northflank and E2B Sandboxes compare on sandbox lifecycle and persistence? E2B creates a Firecracker microVM from a prebooted snapshot. Its SDK controls commands, files, terminals, and services and applies a five-minute default timeout. Teams can pause at timeout and resume later; killing the sandbox permanently removes it. Pause preserves filesystem and memory by default, with a filesystem-only option, and paused sandboxes remain until killed. Continuous runtime is one hour on Hobby and 24 hours on Pro, with custom Enterprise limits; resuming resets that window but disconnects active clients. [Northflank sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) use a service lifecycle rather than a time-boxed session. The UI, API, CLI, or JavaScript client can execute commands, expose ports, restart, scale to zero, or delete them. Sandboxes can be short-lived or long-running, without a fixed session duration. Northflank roots are ephemeral, while [persistent volumes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#create-sandbox-with-volume-for-persistence) preserve repositories, datasets, models, and agent state. [Scale-to-zero](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#pause-or-destroy-the-sandbox) stops compute billing while retaining the volume and service configuration. [Templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code) and [Workflows](https://northflank.com/docs/v1/application/release/configure-workflows) reproduce the wider topology. ## How do Northflank and E2B Sandboxes compare on templates, startup, and scaling? E2B builds Dockerfile or SDK templates into prebooted snapshots and advertises 80 ms same-region starts. It also supports persistent snapshots and live-state forks. Northflank accepts images or Git builds using [Dockerfiles](https://northflank.com/docs/v1/application/build/build-with-a-dockerfile) or [Buildpacks](https://northflank.com/docs/v1/application/build/build-with-buildpacks). MicroVM boot takes under one second; images and workload initialisation affect readiness. Northflank Templates define platform resources, not prebooted VMs. In the 18 June 2026 [ComputeSDK Scale Invitational](https://platform.computesdk.com/scale-invitational), Northflank reached 100,000+ concurrent 0.5-CPU sandboxes from cold start in 24 seconds; E2B reached the target with 2-CPU sandboxes in 29 seconds. This measures fleet scaling, not single-sandbox boot. E2B supports 20 concurrent sandboxes on Hobby and 100 to 1,100 on Pro; Enterprise limits are custom. These limits describe sandbox concurrency, not application autoscaling. Northflank supports vertical scaling, scale-to-zero, and [horizontal autoscaling](https://northflank.com/docs/v1/application/scale/autoscale-deployments) by CPU, memory, requests, or Prometheus metrics. BYOC adds node-pool scaling, spot capacity, custom plans, placement, and scheduling. Northflank has no fixed sandbox-session or concurrency model. ## How do Northflank and E2B Sandboxes compare on storage, networking, and GPU support? E2B includes 10 GiB disk on Hobby and 20 GiB on Pro. Internet is on by default, with allow/deny egress controls and generated port hostnames. Northflank combines ephemeral roots and volumes with private DNS, [multi-project networking](https://northflank.com/docs/v1/application/network/enable-multi-project-networking), [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies), public ports, and BYOC [static egress](https://northflank.com/docs/v1/application/bring-your-own-cloud/configure-static-egress-ips). Northflank supports [GPU-backed sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#create-a-gpu-sandbox), [model-serving services and jobs](https://northflank.com/docs/v1/application/gpu-workloads/gpus-on-northflank). E2B’s public managed offering does not include GPU sandboxes. ## How do Northflank and E2B Sandboxes compare on developer experience? E2B provides JavaScript/TypeScript and Python SDKs for lifecycle, commands, files, terminals, metrics, and networking. Code Interpreter adds `runCode`; the CLI manages sandboxes and templates. Northflank supports [Git-to-deploy](https://northflank.com/docs/v1/application/getting-started/build-and-deploy-your-code), [Dockerfiles](https://northflank.com/docs/v1/application/build/build-with-a-dockerfile), [Buildpacks](https://northflank.com/docs/v1/application/build/build-with-buildpacks), [registries](https://northflank.com/docs/v1/application/run/run-an-image-from-a-container-registry), [Workflows](https://northflank.com/docs/v1/application/release/configure-workflows), [Templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code), [GitOps](https://northflank.com/docs/v1/application/infrastructure-as-code/gitops-on-northflank), [API](https://northflank.com/docs/v1/api/use-the-api), [CLI](https://northflank.com/docs/v1/api/use-the-cli), and [JavaScript client](https://northflank.com/docs/v1/api/use-the-javascript-client). [Northflank Skills](https://github.com/northflank/skills) help Codex, Claude Code, Cursor, and compatible agents deploy and troubleshoot through the API and CLI, subject to credentials, RBAC, and audit controls. ## How do Northflank and E2B Sandboxes compare on previews and production infrastructure? E2B can expose temporary applications but does not orchestrate managed full-stack previews. Northflank [Preview Blueprints](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) create branch or pull-request environments with applications, data, jobs, volumes, private networking, seed workflows, and unique URLs. Northflank offers [Northflank Cloud](https://northflank.com/features/managed-cloud), production BYOC, and BYOK. Self-service BYOC, supported since 2019, retains the customer’s bill, VPC, capacity, and commitments across [AWS](https://northflank.com/cloud/aws), [GCP](https://northflank.com/cloud/gcp), [Azure](https://northflank.com/cloud/azure), and other providers. [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements) connects eligible cloud, on-premises, or bare-metal Kubernetes. Northflank [BYOC and BYOK require](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements) at least 12 vCPUs and 24 GB; BYOC needs at least one node and BYOK three. E2B provides AWS and GCP BYOC through Enterprise rather than public self-service; the agreement defines architecture and responsibility. Northflank BYOC is self-service, with Enterprise assistance available. E2B’s Apache-2.0 self-hosting is separate from Enterprise BYOC and transfers deployment, upgrades, reliability, authentication, and observability to the customer. ## How do Northflank and E2B Sandboxes compare on security, isolation, and observability? E2B uses a Firecracker microVM per sandbox. It provides logs, resource metrics, events, webhooks, access tokens, network restrictions, and best-effort OpenTelemetry export. RBAC is not yet available. Northflank uses [Kata Containers](https://northflank.com/blog/what-are-kata-containers) with [Cloud Hypervisor](https://northflank.com/blog/guide-to-cloud-hypervisor) as its primary microVM approach, with [Firecracker](https://northflank.com/blog/what-is-aws-firecracker) and [gVisor](https://northflank.com/blog/what-is-gvisor) where supported and appropriate. BYOC runtime availability depends on provider, region, and node-pool configuration; Northflank Cloud GPUs use gVisor by default. Northflank provides [logs and metrics](https://northflank.com/docs/v1/application/observe/observability-on-northflank), [health checks](https://northflank.com/docs/v1/application/observe/configure-health-checks), alerts, [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs), log sinks, and [BYOC monitoring](https://northflank.com/docs/v1/application/bring-your-own-cloud/manage-your-cluster). [Enterprise](https://northflank.com/docs/v1/application/enterprise) can include RBAC, SSO, directory sync, scoped access, customer-VPC placement, 24/7 support, SLAs, and FDE onboarding. ## How do Northflank and E2B Sandboxes compare on pricing? E2B adds sandbox usage to plan fees. Northflank bills Cloud compute per second or combines BYOC platform fees with direct infrastructure billing. - **E2B:** Hobby has no plan fee, a one-time $100 credit, 20 concurrent sandboxes, and a one-hour limit. Pro is $150 per month plus usage, includes 100 concurrent sandboxes, offers paid concurrency up to 1,100, and allows 24 hours. CPU and memory are billed per second; Enterprise and BYOC are custom. - **Northflank:** The always-on free Sandbox tier includes two services, one database, and two cron jobs. Self-service [Pay-as-you-go Cloud](https://northflank.com/pricing) has no seat fees and starts at $0.01667 per vCPU-hour and $0.00833 per GB-hour, billed per second, plus storage, network, and GPUs. Enterprise is custom. BYOC combines platform fees with direct cloud-provider billing, preserving credits and commitments. Compare runtime, concurrency, supporting infrastructure, storage, transfer, GPUs, enterprise features, and operations. Northflank can reduce sustained full-stack costs through per-second pricing, no pay-as-you-go seat fees, infrastructure controls, cloud commitments, or BYOC. E2B combines per-second CPU and memory charges with its plan. ## When do E2B Sandboxes fit your requirements? E2B fits teams that want an SDK-first sandbox product while operating the production platform elsewhere. - You want JavaScript/TypeScript or Python SDKs designed specifically for agent sandbox control. - Prebooted VM templates, snapshots, forks, and memory-preserving pause/resume are central requirements. - The Hobby or Pro runtime windows fit, or you will negotiate Enterprise limits. - You operate the supporting production platform elsewhere. - An Enterprise-arranged BYOC deployment on AWS or GCP, or customer-operated open-source self-hosting, fits your responsibility model. ## When does Northflank fit your requirements? Northflank fits teams that need production-grade isolated CPU or GPU sandboxes with control over the complete application stack, deployment location, networking, Kubernetes infrastructure, security, and observability. - Sandboxes must share a control plane with applications, data, previews, and releases. - CPU and GPU workloads need one platform. - Developers need governed self-service without operating Kubernetes directly. - Platform teams need autoscaling, placement, and capacity controls. - Production multi-cloud BYOC, customer-VPC placement, or eligible BYOK on public cloud, on-premises, or bare metal is required. - Direct cloud-provider billing, existing commitments, or infrastructure efficiency materially affect cost. ## Northflank vs E2B Sandboxes: final decision E2B fits when you want an SDK-first product for controlling isolated Linux environments while the production platform remains elsewhere. Northflank fits when sandboxes operate alongside APIs, workers, jobs, queues, databases, private dependencies, observability, or GPUs. It brings these resources into one control plane across Northflank Cloud, self-service production BYOC, or eligible BYOK, with governed developer self-service and platform-team control. **Run sandboxes and their supporting production architecture on Northflank.** One governance model spans sandbox to production without fixed session duration. Kata Containers with Cloud Hypervisor is the primary microVM approach, with Firecracker and gVisor where supported and appropriate. In BYOC, runtime availability and selection depend on the provider, region, and node-pool configuration. Developers use Git, images, API, CLI, Workflows, Templates, or Skills while platform teams retain infrastructure, security, and observability control across Northflank Cloud, production BYOC, or eligible Kubernetes, including on-premises and bare metal. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your requirements. ## Frequently asked questions about Northflank vs E2B Sandboxes These answers cover common buyer questions. ### What is the main difference between Northflank and E2B Sandboxes? Both platforms provide isolated code execution. E2B delivers it through an SDK-first Firecracker sandbox service, while Northflank provides production-grade secure sandboxes through a control plane that also runs services, workers, jobs, managed data, previews, GPUs, and customer-controlled infrastructure. ### Is Northflank an E2B Sandboxes alternative? Yes. Northflank provides programmatically controlled, isolated CPU or GPU sandboxes and also runs the APIs, workers, jobs, managed data, networking, previews, and infrastructure supporting them. E2B provides a specialised SDK-first interface for teams whose primary requirement is Firecracker sandbox creation and control. ### Is Northflank or E2B Sandboxes better for AI-agent sandboxes? E2B fits agents that need programmatic Firecracker environments with template and pause/resume APIs. Northflank fits agents that need isolated CPU or GPU execution alongside production APIs, workers, jobs, managed data, private networking, observability, and customer-cloud infrastructure. ### How do Northflank and E2B Sandboxes preserve sandbox state? E2B’s pause-and-resume flow preserves filesystem and memory, or only the filesystem. Snapshots are independently managed, reusable captures that can create multiple new sandboxes. Northflank persistent volumes preserve repositories, datasets, models, and agent state across restarts and scale-to-zero, while Templates reproduce the wider application topology. ### Does E2B support BYOC? Yes, through an Enterprise engagement rather than a public self-service path. E2B offers BYOC for AWS and GCP. Northflank provides self-service production BYOC across supported cloud providers, with Enterprise assistance available when required. ### Does Northflank or E2B Sandboxes support GPU workloads? Northflank supports GPU-backed sandboxes, services, and jobs on managed or customer-cloud infrastructure. E2B’s public managed offering does not include GPU sandboxes. ### Is Northflank or E2B Sandboxes cheaper? Northflank can reduce sustained full-stack costs through per-second pricing, no pay-as-you-go seat fees, infrastructure controls, and production BYOC. E2B can suit intermittent sandbox-only use through per-second running-sandbox charges. Compare the complete topology and retained operations.

Northflank vs Vercel Sandbox: which platform fits your requirements?

2026-08-28T15:30:00.000Z

Northflank and Vercel Sandbox overlap on isolated code execution but solve different-sized infrastructure problems. Vercel Sandbox is a focused SDK and CLI for Firecracker microVMs. Northflank sandboxes use Kata Containers with Cloud Hypervisor or Firecracker for microVM isolation, plus gVisor where appropriate, within a broader platform for APIs, workers, jobs, managed data, previews, workflows, and CPU or GPU workloads. The decision is whether you need a dedicated execution primitive or one control plane for the sandbox and its supporting production architecture. This comparison covers sandbox lifecycle, isolation, persistence, networking, developer experience, workload support, GPUs, Bring Your Own Cloud (BYOC), Bring Your Own Kubernetes (Northflank BYOK), security, observability, pricing, and operational responsibility. ## TL;DR: Northflank vs Vercel Sandbox - **Vercel Sandbox fits teams that need a specialised sandbox API.** It provides TypeScript and Python SDKs, a CLI, Firecracker microVM isolation, OCI images, automatic persistent sandboxes, snapshots, and active-CPU billing. - **Northflank fits teams that need isolated sandboxes as part of a broader production stack.** It supports Kata Containers with Cloud Hypervisor or Firecracker for microVM isolation and gVisor where appropriate, alongside persistent services and workers, jobs, managed databases and queues, volumes, previews, workflows, and GPU workloads. - **Their infrastructure models differ.** Vercel Sandbox runs on Vercel-managed infrastructure in four regions, while Vercel's AWS BYOC is currently a separate private-beta offering for apps and agents. Northflank offers self-service production multi-cloud BYOC, available since 2019, and eligible Northflank BYOK, including on-premises and bare metal. - **Compare total architecture cost, not one compute rate.** Vercel's active-CPU model can suit bursty or I/O-bound sandbox sessions. Northflank can reduce total cost for sustained production stacks through per-second billing, infrastructure controls, no pay-as-you-go seat fees, and direct cloud-provider billing in BYOC. **Run enterprise agent sandboxes and their supporting systems on Northflank.** Northflank provides governed developer self-service through a strong Kubernetes abstraction, while platform and infrastructure teams retain control over networking, scheduling, security, resources, and observability. Run sandboxes, applications, managed data, previews, workflows, and GPUs on [Northflank Cloud](https://northflank.com/features/managed-cloud), [self-service production BYOC](https://northflank.com/features/bring-your-own-cloud), available since 2019, or [eligible BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements). [Northflank Skills](https://github.com/northflank/skills) help Codex, Claude Code, and Cursor operate through governed API and CLI access. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## Northflank vs Vercel Sandbox comparison table | Requirement | Northflank | Vercel Sandbox | | --- | --- | --- | | Best for | Enterprises, platform organisations, AI engineering teams, and startups needing governed self-service across sandboxes, applications, managed data, GPUs, and managed or customer-controlled infrastructure | Teams needing a focused Vercel-integrated SDK for code execution, agents, playgrounds, and development servers | | Product scope | Mature application and infrastructure platform for sandboxes and complete production stacks | Specialised sandbox compute product within Vercel | | Isolation | Kata Containers with Cloud Hypervisor as the primary production microVM approach, with Firecracker and gVisor available depending on workload and infrastructure; Northflank Cloud GPU workloads currently use gVisor by default | Firecracker microVM per sandbox | | Lifecycle | Under-one-second sandbox boot; ephemeral or long-running services with programmatic create, pause, resume, restart, and destroy | Five-minute default; 45-minute Hobby and 24-hour Pro/Enterprise maximum per session; GA persistence restores filesystem state between sessions | | Environment creation | Git repositories, Dockerfiles, buildpacks, compatible container images, templates, API, CLI, JavaScript client, and persistent volumes | Vercel Managed Images, public-beta custom OCI images, files, Git repository sources, automatic persistence, snapshots, and private-beta Drives | | Compute | 0.1–32 vCPU and 256 MB–256 GB memory on Northflank Cloud; custom resource plans in BYOC | 2 GB RAM per vCPU; up to 4 vCPU Hobby, 8 Pro, and 32 Enterprise | | GPUs | GPU-backed sandboxes, services, and jobs using managed or BYOC GPU node pools | No GPU compute option for Sandbox | | Filesystem | Ephemeral root filesystem; persistent volumes preserve repositories, datasets, models, or agent state across restarts and pauses | Persistent by default with automatic filesystem snapshots and restore; private-beta Drives provide sandbox-independent storage | | Networking | Private networking across sandboxes and supporting workloads, public ports, network policies, multi-project access, configurable static egress, and customer-VPC routing through BYOC | Host-enforced egress firewall, live policy updates, credential brokering, request filtering and proxying; up to 15 ports | | Interfaces | UI, API, CLI, JavaScript client, images, templates, GitOps, Workflows, and Skills | TypeScript/Python SDKs and Sandbox CLI | | Supporting workloads | Services, workers, jobs, databases, queues, volumes, workflows, and GPUs | Separate Vercel products provide Functions, beta Services, Workflows, storage, Queues, and deployments | | Preview environments | Preview Blueprints create full-stack environments with data, jobs, volumes, networking, seed workflows, and URLs | Exposed sandbox ports; Vercel Deployments separately provide web previews | | Infrastructure | Northflank Cloud; self-service production multi-cloud BYOC since 2019; eligible cloud, on-premises, and bare-metal BYOK | Vercel-managed Sandbox in `iad1`, `sfo1`, `cle1`, and `cdg1`; no Sandbox BYOC, BYOK, or self-hosting option | | Observability | Build, sandbox, service, job, and addon logs and metrics; health checks, alerts, audit logs, and external log sinks | Command output, live logs, active-sandbox view, and metrics | | Enterprise | Governed developer self-service with RBAC, SSO, directory sync, audit logs, scoped API access, policies, customer-VPC options, SLAs, 24/7 support, and FDE onboarding | Vercel's wider platform includes RBAC, SSO, Directory Sync, audit logs, and compliance controls, with availability and scope varying by product and plan | | Pricing | Free always-on account tier; transparent per-second Cloud pricing without pay-as-you-go seat fees; direct cloud-provider billing in BYOC; custom Enterprise pricing | Active CPU, memory, creation, network, snapshot, and image-storage usage; Drives free during private beta | ## Who are Northflank and Vercel Sandbox designed for? Vercel Sandbox is designed for engineers who want on-demand execution embedded in an application. Its SDK abstracts microVM creation, commands, files, processes, ports, persistence, and teardown for generated code, uploads, playgrounds, and development servers. Northflank is designed for enterprises, platform organisations, AI engineering teams, and startups that need sandboxes within a broader production architecture. [Northflank sandboxes](https://northflank.com/features/sandboxes) are services that use compatible images, execute commands, expose ports, attach volumes, run on CPU or GPU resources, and support programmatic lifecycle control. The Northflank control plane can run the agent API, scheduler, workers, jobs, queues, databases, model-serving workloads, and telemetry. Developers receive a self-service abstraction instead of direct Kubernetes access, while platform teams retain infrastructure and governance controls. ## How do Northflank and Vercel Sandbox compare on lifecycle, templates, and persistence? Vercel exposes a dedicated sandbox-and-session abstraction. Northflank models a sandbox as an isolated service whose lifecycle can be coordinated with the surrounding application. Vercel Sandbox's `Sandbox.create()` starts a five-minute session. Maximum duration is 45 minutes on Hobby and 24 hours on Pro and Enterprise, with extensions within that limit. Vercel Sandbox discards non-persistent filesystems on stop. Vercel Sandbox persistence is generally available and enabled by default. Vercel Sandbox snapshots the filesystem when a session stops and restores it when activity resumes. Teams can disable persistence for ephemeral workloads; snapshots incur storage charges. Private-beta Drives on Pro and Enterprise provide sandbox-independent storage for non-critical data. Northflank starts compatible images on [Northflank Cloud or BYOC](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank), with programmatic create, start, pause, restart, and destroy operations. Sandbox boot takes under one second, while end-to-end readiness depends on image retrieval and workload initialization. Northflank volumes preserve repositories, agent state, datasets, or models beyond the ephemeral root filesystem. [Templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code) reproduce a sandbox or complete topology; unlike snapshots, they are infrastructure definitions. Northflank sandboxes follow a service lifecycle rather than fixed-duration sessions. Teams can automate pause, restart, scale, or teardown with the application lifecycle. ## Which workloads and resources do Northflank and Vercel Sandbox support? Northflank supports a broader production topology, while Vercel Sandbox gives isolated sessions a focused execution interface. Vercel Sandbox SDK v3 defaults to Managed Images instead of the deprecated named `runtime` options. Its universal image uses Ubuntu 26.04 with Node.js 24, Python 3.14, coding agents, and common tools; Vercel also supplies language-specific images and supports public-beta custom OCI images. A sandbox can also start from a public or authenticated private Git repository source, which is separate from Vercel's Git-triggered deployment workflow. Limits are 4 vCPUs on Hobby, 8 on Pro, and 32 on Enterprise, with 2 GB RAM per vCPU. Vercel Sandbox operates in `iad1`, `sfo1`, `cle1`, and `cdg1` and does not offer GPU compute. Vercel Functions remain separate request-driven compute. Beta Vercel Services adds long-running and backend-only workloads, private service communication, and Dockerfile support. Services, deployments, Workflows, storage, and Queues can support agents but remain outside the Sandbox lifecycle API. Northflank runs compatible container images as isolated sandboxes, persistent services and workers, or one-off, scheduled, and API-triggered jobs. Northflank Cloud plans range from 0.1 to 32 vCPU and 256 MB to 256 GB of memory, while BYOC supports custom resource plans and workload placement. Persistent volumes can attach to sandbox or application workloads, and [managed addons](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank) provide databases, caches, queues, and object storage in the same control plane. Northflank supports [GPU sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank), model-serving services, and GPU jobs in GPU-enabled Northflank regions or compatible BYOC node pools. Teams can separate CPU and GPU pools, control placement, and run sandbox execution beside the APIs, queues, data, and workers that support an agent. Northflank supports vertical scaling, scale-to-zero, and [horizontal autoscaling](https://northflank.com/docs/v1/application/scale/autoscale-deployments) by CPU, memory, requests, or custom Prometheus metrics. BYOC adds node-pool scaling, spot capacity, custom plans, and scheduling controls. Vercel Sandbox permits 10 concurrent sandboxes on Hobby and 10,000 by default on Pro and Enterprise, with a dynamic allocation quota that can ramp up to 5,000 vCPUs per minute. Northflank does not use a fixed sandbox-session duration or concurrency model: sandbox services can remain running, pause, or scale with the application. Northflank Cloud quotas and available capacity still apply, while BYOC capacity depends on the customer's clusters and node pools. ## How do Northflank and Vercel Sandbox compare on networking, security, and observability? Both platforms are designed for isolated execution of untrusted code. Northflank extends networking and governance across the surrounding production infrastructure. Each Vercel Sandbox uses a Firecracker microVM with its own filesystem and network. Its host-enforced firewall supports allow-all, deny-all, domain and CIDR rules, and live updates. Credential brokering keeps secrets outside the guest; beta request matchers and proxying filter or forward selected traffic. Configured ports use unique sandbox URLs rather than private VPC connectivity. Northflank supports multiple isolation runtimes. [Kata Containers](https://northflank.com/blog/what-are-kata-containers) runs containers inside microVMs using [Cloud Hypervisor](https://northflank.com/blog/guide-to-cloud-hypervisor) or [Firecracker](https://northflank.com/blog/what-is-aws-firecracker), while [gVisor](https://northflank.com/blog/what-is-gvisor) provides a user-space kernel boundary. Kata with Cloud Hypervisor is Northflank's primary production microVM approach; Northflank Cloud GPU workloads use gVisor by default, and BYOC uses the runtime selected for its node pool. Private networking connects application resources, with policies, multi-project access, [configurable static egress](https://northflank.com/docs/v1/application/network/configure-egress-ips), and customer-VPC routing. Vercel provides command output, live logs, active-sandbox views, and metrics; wider observability is separate. Northflank provides [logs and metrics](https://northflank.com/docs/v1/application/observe/observability-on-northflank) across sandboxes, services, builds, jobs, and addons, alongside [health checks](https://northflank.com/docs/v1/application/observe/configure-health-checks), [infrastructure alerts](https://northflank.com/docs/v1/application/observe/set-infrastructure-alerts), [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs), [external log sinks](https://northflank.com/docs/v1/application/observe/configure-log-sinks), and [BYOC cluster monitoring](https://northflank.com/docs/v1/application/bring-your-own-cloud/manage-your-cluster). Vercel's wider platform offers RBAC, SAML SSO, Directory Sync, audit logs, and compliance programmes. Paid Enterprise Secure Compute supplies an isolated network, outbound IPs, and VPC peering for supported Vercel workloads, but it is separate from a Sandbox BYOC deployment model. Northflank provides granular RBAC, scoped API roles, secrets, SSO, directory sync, audit logs, and policies. [Enterprise](https://northflank.com/docs/v1/application/enterprise) can include customer-VPC operation, 24/7 support and SLAs, infrastructure audits, and forward-deployed engineering onboarding. ## How do Northflank and Vercel Sandbox compare on deployment and developer experience? Vercel provides a sandbox-specific SDK workflow, while Northflank provides sandbox automation within a broader deployment and infrastructure platform. Vercel provides TypeScript and Python SDKs plus a CLI. OIDC authenticates Vercel deployments; tokens support external apps and CI. AI SDK tooling and an OpenAI Agents SDK example extend integration. Northflank supports [Git-to-deploy](https://northflank.com/docs/v1/application/getting-started/build-and-deploy-your-code), [Dockerfiles](https://northflank.com/docs/v1/application/build/build-with-a-dockerfile), [buildpacks](https://northflank.com/docs/v1/application/build/build-with-buildpacks), and [registries](https://northflank.com/docs/v1/application/run/run-an-image-from-a-container-registry). Automation includes [Workflows](https://northflank.com/docs/v1/application/release/configure-workflows), [templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code), [GitOps](https://northflank.com/docs/v1/application/infrastructure-as-code/gitops-on-northflank), [API](https://northflank.com/docs/v1/api/use-the-api), [CLI](https://northflank.com/docs/v1/api/use-the-cli), and [JavaScript client](https://northflank.com/docs/v1/api/use-the-javascript-client). [Northflank Skills](https://github.com/northflank/skills) guide compatible coding agents such as Codex, Claude Code, Cursor, and others in deployment and troubleshooting through the API and CLI. Credentials, RBAC, and audit controls still apply. Vercel Sandbox can expose a server inside one sandbox; Vercel Deployments separately provide web previews. Northflank [Preview Blueprints](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) can create per-branch or pull-request stacks with services, jobs, databases, volumes, private networking, seed workflows, and URLs. ## How do Northflank and Vercel Sandbox compare on BYOC and private infrastructure? Northflank has a mature production multi-cloud model. Vercel Sandbox runs on Vercel-managed infrastructure, while Vercel's AWS BYOC is currently a separate private-beta offering for apps and agents. Northflank has supported production Bring Your Own Cloud (BYOC) since 2019 across [AWS](https://northflank.com/cloud/aws), [GCP](https://northflank.com/cloud/gcp), [Azure](https://northflank.com/cloud/azure), and other supported providers. Customers own the account, network, capacity, and infrastructure bill. Northflank Bring Your Own Kubernetes (BYOK) connects eligible public-cloud, on-premises, or bare-metal clusters. [Northflank currently requires](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements) at least 12 vCPUs and 24 GB per BYOC or BYOK cluster. BYOC requires a minimum of one node, while BYOK requires a minimum of three nodes, with compatible networking and storage. Vercel's AWS BYOC for apps and agents is private beta. Vercel Sandbox currently runs on Vercel-managed infrastructure rather than through a customer-cloud deployment option. Vercel does not offer BYOK, on-premises, bare-metal, or supported Sandbox self-hosting. ## How do Northflank and Vercel Sandbox compare on pricing? Vercel meters individual Sandbox resources and activity. Northflank bills Northflank Cloud compute per second; in BYOC, Northflank charges platform fees while the cloud provider bills the customer directly for infrastructure. - **Vercel Sandbox:** Pro costs $20 per month for one deploying seat and includes a $20 usage credit. Starting rates are $0.128 per active vCPU-hour and $0.0212 per provisioned GB-hour, with separate charges for creations, transfer, snapshots, and images. CPU bills only while active; memory bills for the session's wall-clock duration. This can suit short or I/O-heavy sessions. - **Northflank:** The free Sandbox account tier provides always-on compute with two services, one database, and two cron jobs; it is distinct from isolated sandbox workloads. [Northflank Cloud pricing](https://northflank.com/pricing) is billed per second without pay-as-you-go seat fees, starting at $0.01667 per vCPU-hour and $0.00833 per GB-hour, plus storage and egress. BYOC combines Northflank platform fees with direct cloud-provider billing, preserving negotiated rates, credits, and commitments. This can reduce total cost for sustained production stacks while customers retain responsibility for their cloud account, network, capacity, and policies. ## When does Vercel Sandbox fit your requirements? Vercel Sandbox fits teams that need a focused, vendor-operated sandbox runtime closely integrated with the Vercel ecosystem. - You want a focused SDK for creating microVMs, executing commands, managing files, and exposing temporary development servers. - Your application already runs on Vercel and OIDC, AI SDK, Vercel projects, and Vercel observability reduce integration work. - Default automatic persistence and snapshots fit your lifecycle; private-beta Drives are acceptable for non-critical state. - Vercel Managed Images or custom OCI images cover execution requirements. - You are comfortable running sandboxes on Vercel-managed infrastructure and do not need BYOK, on-premises deployment, GPUs, or Kubernetes-level controls. - Active-CPU billing suits agents that spend significant time waiting on models, APIs, or users. ## When is Northflank a Vercel Sandbox alternative? Northflank is a Vercel Sandbox alternative when isolated execution must operate as part of a complete production architecture. Both platforms can run untrusted or agent-generated code, but Northflank also manages the APIs, workers, jobs, databases, queues, volumes, previews, workflows, observability services, and GPU workloads around each sandbox. Northflank is therefore less like a replacement sandbox SDK and more like a broader control plane. That distinction matters when platform teams need production BYOC, eligible BYOK, customer-VPC networking, Kubernetes-level infrastructure control, or governed developer self-service. Teams that only need a focused execution API closely integrated with Vercel may find Vercel Sandbox more direct. ## When does Northflank fit your requirements? Northflank fits teams that need sandbox execution within a broader application and infrastructure control plane. - Sandboxes must run beside APIs, persistent workers, jobs, databases, queues, volumes, and release workflows. - You need GPU sandboxes, model-serving services, or GPU jobs in the same control plane. - Full-stack ephemeral environments must reproduce several interconnected components. - Developers need governed self-service while platform teams control networks, resources, scheduling, node pools, policies, and observability. - You want Kubernetes infrastructure without requiring each developer to manage Kubernetes directly. - You need production multi-cloud BYOC, eligible BYOK, on-premises or bare-metal Kubernetes, or private customer-VPC placement. - Direct cloud-provider billing, cloud commitments, spot capacity, custom plans, or workload placement affect total cost. ## Northflank vs Vercel Sandbox: final decision Vercel Sandbox fits isolated execution through a dedicated SDK, especially when the surrounding application already runs on Vercel. It combines Firecracker microVMs with automatic persistence, snapshots, egress policies, OCI image support, and active-CPU billing. It is the narrower option when the requirement is sandbox execution rather than a broader application platform. Northflank fits when sandboxes must operate alongside APIs, workers, jobs, queues, databases, private dependencies, observability services, or GPU inference. It combines Kata Containers with Cloud Hypervisor or Firecracker, plus gVisor where appropriate, with persistent services, managed data, volumes, previews, workflows, and CPU or GPU workloads in one control plane. Teams can run that architecture on Northflank Cloud, self-service production multi-cloud BYOC, or eligible BYOK while developers receive governed self-service and platform teams retain infrastructure control. **Build the sandbox and its production architecture on one platform.** Northflank combines Kata, Firecracker, or gVisor-backed isolation, depending on workload and infrastructure, with services, jobs, managed data, volumes, workflows, previews, and GPUs across Northflank Cloud, production BYOC, or eligible BYOK. Developers get Kubernetes abstraction; infrastructure teams retain cluster, network, scheduling, security, and observability controls. Enterprise options include customer-VPC operation, 24/7 support and SLAs, and forward-deployed engineering onboarding. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## Frequently asked questions about Northflank vs Vercel Sandbox ### What is the main difference between Northflank and Vercel Sandbox? Vercel Sandbox is an SDK-managed microVM service. Northflank includes sandboxes in a control plane for applications, managed data, GPUs, and Kubernetes infrastructure. ### Is Northflank or Vercel Sandbox better for AI-agent sandboxes? Vercel fits agents needing focused SDKs. Northflank fits when sandboxes share a platform with APIs, queues, data, workers, private networking, or GPUs. ### How do Northflank and Vercel Sandbox preserve state? Northflank persistent volumes preserve repositories, datasets, models, and agent state across restarts and pauses, while templates reproduce the wider application topology. Vercel Sandbox automatically snapshots and restores its filesystem; private-beta Drives provide sandbox-independent storage. ### Does Vercel Sandbox support BYOC? Vercel Sandbox currently runs on Vercel-managed infrastructure. Vercel's AWS BYOC is a private-beta offering for apps and agents rather than a Sandbox deployment option. ### Does Northflank or Vercel Sandbox support GPU workloads? Northflank supports GPU sandboxes, services, and jobs where compatible capacity is available. Vercel Sandbox does not currently offer GPU compute. ### Is Northflank or Vercel Sandbox cheaper? Northflank can reduce sustained full-stack costs through no pay-as-you-go seat fees and production BYOC. Vercel's active-CPU model can suit short or I/O-heavy sessions. Compare memory, concurrency, storage, transfer, supporting services, and operations.

Northflank vs Heroku: which platform fits your applications and team?

2026-08-27T16:54:00.000Z

Northflank and Heroku both simplify application deployment but provide different infrastructure boundaries. Heroku centres on apps, dynos, buildpacks, and add-ons on Heroku infrastructure. Northflank abstracts Kubernetes across Northflank Cloud, your own cloud accounts, and eligible existing clusters. This comparison covers target users, workloads, developer experience, previews, infrastructure, private networking, scaling, observability, security, Bring Your Own Cloud (BYOC), pricing, and operational responsibility. ## TL;DR: Northflank vs Heroku - **Heroku fits teams that want a fully managed app-and-dyno platform.** Its dyno model, buildpacks, add-ons, Pipelines, Review Apps, and CLI suit web applications that can remain on Heroku-operated infrastructure. New buyers should note that Heroku stopped offering Enterprise Account contracts to new customers in February 2026, although self-service credit-card access remains available and existing Enterprise subscriptions can renew. - **Northflank fits enterprise and platform teams that need governed developer self-service with infrastructure choice.** Its Kubernetes abstraction covers production full-stack applications, services, jobs, managed data, automated previews, autoscaling, volumes, and optional GPUs across Northflank Cloud, production BYOC, and eligible BYOK. Startups and individual engineers can use the same platform. - **Heroku exposes fewer infrastructure decisions.** Northflank can expose cluster, node-pool, resource, networking, placement, and observability controls when platform teams need them, without requiring application developers to operate Kubernetes directly. - **Pricing follows different operating models.** Heroku combines dyno, data-service, add-on, and, where applicable, Private Space or Enterprise charges. Review Apps incur normal resource charges. Northflank Cloud meters resources by the second without pay-as-you-go seat fees; Northflank BYOC combines platform fees with infrastructure billed directly by your cloud provider. For infrastructure placement or broader workloads, [Northflank](https://northflank.com/) provides governed developer self-service across [Northflank Cloud](https://northflank.com/features/managed-cloud), [production BYOC and BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements), and [GPU-backed services and jobs](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud). [Northflank Skills](https://github.com/northflank/skills) extend these workflows to coding agents. Platform teams control clusters, networks, resources, and policies without making developers operate Kubernetes. Northflank has [supported production BYOC since 2019](https://northflank.com/blog/is-byoc-the-future-of-software-deployment). [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, cost, or migration requirements. ## Northflank vs Heroku comparison table The table summarises the differences most likely to change a deployment-platform decision. Product and pricing details were checked on 27 August 2026. | Requirement | Northflank | Heroku | | --- | --- | --- | | Best for | Enterprise and platform teams that need governed developer self-service, Kubernetes abstraction, automated full-stack previews, autoscaling, and one control plane for production workloads across Northflank Cloud, multi-cloud BYOC, eligible BYOK, and optional GPUs | Teams that want Heroku's app-and-dyno deployment model, maintained buildpacks, a broad add-on ecosystem, and a fully managed runtime | | Infrastructure model | Northflank Cloud; production BYOC in the customer's cloud account; eligible BYOK in public cloud, on-premises, or bare metal | Cedar Common Runtime; Cedar or Fir Private Spaces; Cedar-only Shield Private Spaces | | Workloads | Services and workers; one-off jobs triggered manually, through the API, or from a workflow; scheduled jobs; managed data; volumes; CPU or optional GPU containers | Web, worker, and custom process types; one-off dynos; scheduled tasks; attached data services and add-ons | | Build and deployment | Git, Dockerfile, buildpacks, external images, combined or separate CI/CD, Workflows, Templates, GitOps, API, and CLI | Git, GitHub, buildpacks, API, Procfile, Pipelines, CLI, and Cedar container deployment | | Preview environments | Automated full-stack Northflank Preview Blueprints for pull requests or branch pushes, with frontends, services, databases, jobs, volumes, private networking, seed or restore workflows, unique URLs, and configurable cleanup | Automatic or manual Review Apps for GitHub pull requests through Pipelines and GitHub integration, with normally billed app resources and eligible declared add-ons | | Data and persistence | Managed databases, caches, queues, and object storage with backups, scaling, high-availability options, and upgrades; persistent volumes for custom stateful software | Heroku Postgres, Heroku Key-Value Store, Apache Kafka on Heroku, marketplace add-ons; ephemeral dyno filesystems | | Private networking | Private networking across services, jobs, databases, and addons; multi-project networking, network policies, secure external access, and workload placement inside the customer's VPC or network through BYOC | Cedar and Fir Private Spaces provide isolated networking and stable outbound IPs; internal routing, VPC peering, VPN, and Shield Spaces remain Cedar-only | | Scaling and resources | Explicit replicas; CPU, memory, RPS, or custom-metric autoscaling; vertical plans; BYOC node pools, spot capacity, and placement controls | Manual dyno quantity and size; response-time autoscaling for eligible Performance, Private, and Shield Cedar web dynos; no current Fir autoscaling | | GPU workloads | GPU services and jobs on Northflank Cloud or BYOC node pools | Heroku does not currently offer GPU dynos | | Observability | Live and historical build, service, job, and addon logs and metrics; health checks, alerts, log sinks, and scoped audit events | Aggregated runtime logs with limited Cedar history and no Fir history; separate build logs; plan-dependent metrics, drains, add-ons, and Fir OpenTelemetry | | Enterprise controls | Granular RBAC, SAML/OIDC SSO, directory sync, audit logs, scoped API access, workload identities, network controls, customer-controlled deployment options, SLAs, 24/7 support, and forward-deployed options | Existing Enterprise customers can use Enterprise Accounts and Teams, SSO, app permissions, audit exports, Private Spaces, Cedar-only Shield controls, and enterprise support; Heroku no longer offers new Enterprise Account contracts | | Pricing model | Always-on free Sandbox; self-service per-second usage with no seat fees; custom Enterprise; BYOC platform fees plus direct cloud-provider billing | $5 monthly flat-fee Eco pool for personal apps; other dynos billed per second up to monthly caps; data services, add-ons, Private Spaces, and eligible contract charges are additional | | Operational responsibility | Northflank operates the platform; responsibility varies across Northflank Cloud, BYOC, and BYOK | Heroku operates runtime infrastructure; customers own applications, configuration, access choices, and data use | ## Who are Northflank and Heroku designed for? ### Heroku Heroku serves developers and application teams deploying twelve-factor web applications, APIs, workers, and scheduled or one-off processes. Applications declare process types that run in independently scalable dynos, while Heroku data services and marketplace add-ons provide databases and supporting infrastructure. Heroku spans Cedar and Fir. Cedar supports Common Runtime and Cedar Private Spaces. Fir is generally available through Fir Private Spaces and is implemented on Kubernetes and OCI/OpenTelemetry standards while retaining Heroku's dyno-facing model. Fir has not reached parity with Cedar across networking, autoscaling, Shield compliance, CI, and container-build features. Heroku moved to a sustaining engineering model in February 2026, focused on stability, security, reliability, and support rather than new feature development. It also stopped offering Enterprise Account contracts to new customers. Existing Enterprise subscriptions and support contracts can renew, while new and existing customers paying by credit card can continue using Heroku without this contract. ### Northflank Northflank gives developers self-service builds, deployments, databases, jobs, and environments while platform engineers govern access, networks, clusters, capacity, placement, and observability. Northflank provides one control plane for production full-stack applications, services, jobs, managed data, automated previews, autoscaling, and optional GPU workloads. Enterprises, startups, and individual engineers use the same developer workflow. [Northflank Skills](https://github.com/northflank/skills) give compatible coding agents such as Codex, Claude Code, and Cursor Northflank-specific guidance for deploying, operating, and troubleshooting workloads through the API and CLI. Authentication, RBAC, and audit controls still govern what each agent can do. ## What are the main differences between Northflank and Heroku? Heroku standardises applications around dynos; Northflank standardises a broader Kubernetes-backed stack across managed and customer-controlled infrastructure. ### Application and workload support Heroku's web, worker, and custom dynos handle continuous processes; one-off dynos handle maintenance, and Scheduler runs recurring commands. Dyno filesystems are ephemeral, so persistent data belongs in a backing service. Northflank runs [compatible container images as persistent services and workers](https://northflank.com/docs/v1/application/run/run-containers-and-micro-services), alongside [one-off and scheduled jobs](https://northflank.com/docs/v1/application/run/run-an-image-once-or-on-a-schedule) that can be started manually, [through the API](https://northflank.com/docs/v1/api/use-the-api), or from a workflow. [Managed addons](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank) cover databases, caches, queues, and object storage, while [persistent volumes](https://northflank.com/docs/v1/application/databases-and-persistence/add-a-volume) support custom stateful software. On Northflank, teams can run these resources as one connected stack, apply [private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank) and [shared secret groups](https://northflank.com/docs/v1/application/secure/manage-secret-groups), and use [Northflank Workflows](https://northflank.com/docs/v1/application/release/configure-workflows) to coordinate releases, jobs, migrations, addons, and image promotion. Northflank also supports [GPU-backed services and jobs](https://northflank.com/docs/v1/application/gpu-workloads/gpus-on-northflank) on managed GPU plans or customer-cloud GPU nodes. Heroku does not currently offer GPU dynos. ### Deployment workflow and developer experience Heroku builds a repository, reads commands from a Procfile, and runs them as dynos. Pipelines group environments and promote artifacts; configuration and add-ons remain per app. Heroku's Container Registry and `container` stack and its `heroku.yml` Docker-build workflow are Cedar-only. Fir builds application images exclusively with Cloud Native Buildpacks. Northflank provides Git-to-deploy with [Dockerfiles](https://northflank.com/docs/v1/application/build/build-with-a-dockerfile), [buildpacks](https://northflank.com/docs/v1/application/build/build-with-buildpacks), or [external registry images](https://northflank.com/docs/v1/application/run/run-an-image-from-a-container-registry). Builds and deployments can remain combined or separate. Northflank [Workflows](https://northflank.com/docs/v1/application/release/configure-workflows) coordinate multi-step releases, jobs, backups, and approvals. [Templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code) define reusable application stacks, while [GitOps](https://northflank.com/docs/v1/application/infrastructure-as-code/gitops-on-northflank) keeps platform configuration synchronised with a Git repository. Teams can use the Northflank [API](https://northflank.com/docs/v1/api/use-the-api) and [CLI](https://northflank.com/docs/v1/api/use-the-cli) to automate and manage these resources outside the dashboard. Teams planning a move can use the [step-by-step Heroku migration guide](https://northflank.com/blog/how-to-migrate-from-heroku-a-step-by-step-guide) to understand the overall process, then follow the [Heroku migration documentation](https://northflank.com/docs/v1/application/migrate-from-heroku) to map applications, processes, environment variables, data, and deployment configuration to Northflank. ### Infrastructure and deployment model Heroku runs dynos in Cedar Common Runtime, Cedar or Fir Private Spaces, and Cedar-only Shield Spaces. Cedar can peer with your AWS VPC, but dynos remain on Heroku infrastructure, so peering is not BYOC. Northflank offers three models through one application control plane. [Northflank Cloud](https://northflank.com/features/managed-cloud) is the managed option. With [Bring Your Own Cloud (BYOC)](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements), Northflank provisions and manages a new Kubernetes cluster in your cloud account. With [Bring Your Own Kubernetes (BYOK)](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements#byok-requirements), Northflank connects an eligible existing cluster. Northflank production BYOC, supported since 2019, covers [AWS](https://northflank.com/cloud/aws), [GCP](https://northflank.com/cloud/gcp), [Azure](https://northflank.com/cloud/azure), [Civo](https://northflank.com/cloud/civo), [Oracle Cloud](https://northflank.com/cloud/oci), [CoreWeave](https://northflank.com/cloud/coreweave), and [Nebius](https://northflank.com/cloud/nebius). [Northflank BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements#byok-requirements) can use eligible public-cloud, on-premises, or bare-metal Kubernetes, but requires a preferably dedicated cluster with compatible networking, storage, DNS, load balancing, and minimum capacity. A Northflank BYOC or BYOK cluster requires at least 12 vCPU and 24 GB in total. Northflank BYOC supports a minimum of one node, while BYOK requires at least three nodes; each node must provide at least 4 vCPU and 8 GB of memory. With Northflank BYOC, your organisation owns the account, bill, commitments, capacity, and cloud controls; Northflank manages the provisioned cluster and application platform. ### Preview environments and private networking Heroku Review Apps can be created automatically or manually from GitHub pull requests and require Pipelines plus GitHub integration. Eligible add-ons and dynos receive normal charges, and Fir lacks predictable Review App URLs. [Northflank Preview Blueprints](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) automatically create multi-resource preview environments from pull requests or branch pushes, including frontend and backend services, databases, jobs, volumes, secrets, private networking, seed or restore workflows, and unique URLs. Configurable cleanup can remove previews when pull requests close or merge. Heroku's Cedar and Fir Private Spaces provide isolated networking and stable outbound IPs. Internal routing, DNS service discovery, AWS VPC peering, IPSec VPN, and Shield Spaces remain Cedar-only. Northflank provides [private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank) across workloads and data services, with isolated projects, cross-project ingress, network policies, secure external access, and BYOC VPC placement. ### Scaling, resources, and GPU workloads Heroku scales by dyno size and process-type count. Performance, Private, and Shield Cedar web dynos can autoscale using response-time and throughput behaviour; Fir autoscaling is not currently available. Northflank lets teams [set instance counts](https://northflank.com/docs/v1/application/scale/scale-instances), choose CPU and memory, or [autoscale deployments](https://northflank.com/docs/v1/application/scale/autoscale-deployments) using CPU, memory, requests per second, or custom Prometheus metrics. BYOC adds [custom resource plans](https://northflank.com/docs/v1/application/bring-your-own-cloud/create-custom-resource-plans), [spot nodes](https://northflank.com/docs/v1/application/bring-your-own-cloud/deploy-and-scale-node-pools), [workload affinity](https://northflank.com/docs/v1/application/bring-your-own-cloud/deploy-workloads-to-your-cluster), [separate build capacity](https://northflank.com/docs/v1/application/bring-your-own-cloud/configure-your-cluster), [node-pool scaling](https://northflank.com/docs/v1/application/bring-your-own-cloud/deploy-and-scale-node-pools), and [placement controls](https://northflank.com/docs/v1/application/bring-your-own-cloud/deploy-workloads-to-your-cluster). ### Observability Heroku aggregates application, system, router, API, and eligible add-on runtime logs; build logs are separate. Cedar provides a bounded Logplex buffer, while Fir has no log history. Durable retention requires an add-on or drain. Heroku application metrics are unavailable on Eco dynos. Basic dynos provide 24 hours of metrics at 10-minute resolution, while other eligible dyno tiers provide longer history and finer resolution. Heroku's Fir generation integrates OpenTelemetry and Telemetry Drains. Northflank provides [live and historical logs](https://northflank.com/docs/v1/application/observe/view-logs) for builds, services, jobs, and addons, alongside [resource metrics](https://northflank.com/docs/v1/application/observe/view-metrics) for monitoring workload performance. Teams can configure [health checks](https://northflank.com/docs/v1/application/observe/configure-health-checks) and [infrastructure alerts](https://northflank.com/docs/v1/application/observe/set-infrastructure-alerts), review scoped activity through [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs), and export logs to external systems using [log sinks](https://northflank.com/docs/v1/application/observe/configure-log-sinks). In Northflank BYOC, the same control plane also provides visibility into clusters and node pools, connecting application-level signals with the infrastructure running those workloads. ## How do Northflank and Heroku compare on security and enterprise controls? Heroku centralises runtime operations. Northflank can extend the application control plane into customer-controlled cloud or Kubernetes infrastructure. Heroku Enterprise provides accounts and teams, SSO, mandatory MFA, app permissions, Private Spaces, Cedar-only Shield controls, and monthly audit exports. Shield Spaces remain Cedar-only, and Heroku lists HIPAA compliance for Fir as forthcoming. Buyers should confirm the current compliance scope before using Fir for regulated workloads. These capabilities do not mean a new Enterprise Account contract is available. Heroku stopped offering those contracts to new customers in February 2026; existing Enterprise subscriptions and support contracts remain supported and can renew. New buyers can still use Heroku through credit-card billing, but teams that require a negotiated enterprise contract should treat contract availability as a decision constraint. Northflank provides [granular RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [scoped API access](https://northflank.com/docs/v1/application/secure/grant-api-access), [SAML or OIDC SSO](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation#configure-single-sign-on-sso), [directory sync](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation#sync-your-directory), [MFA](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication), [secrets](https://northflank.com/docs/v1/application/secure/manage-secret-groups), [network controls](https://northflank.com/docs/v1/application/network/configure-network-policies), [workload identities](https://northflank.com/docs/v1/application/enterprise), [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs), and [infrastructure events](https://northflank.com/docs/v1/application/enterprise). Enterprise adds HA/DR, 24/7 support, SLAs, and customer-VPC, on-premises, forward-deployed, or air-gapped options. Northflank is SOC 2 Type 2 and HIPAA compliant, with BAAs supported under Enterprise contracts. Heroku fits vendor-operated infrastructure; Northflank fits governance spanning customer VPCs, Kubernetes, multi-cloud, or deeper controls. ## How do Northflank and Heroku pricing and responsibility compare? Heroku combines dyno and data-service pricing with separate add-on and Private Space charges; Enterprise pricing applies to existing Enterprise contracts because Heroku no longer offers them to new customers. Northflank offers usage-based pricing for Northflank Cloud and custom Enterprise pricing that can include commitments, SLAs, 24/7 support, and onboarding. Northflank BYOC keeps infrastructure charges on your cloud-provider bill while adding Northflank platform fees. - **Heroku:** There is no free dyno tier. Personal-account Eco costs $5 per month for a shared pool of 1,000 dyno hours and sleeps after 30 minutes of inactivity. Basic is prorated up to $7 per dyno monthly; Standard-1X up to $25. Data services, add-ons, CI, and Private or Shield resources add costs. Review Apps and one-off dynos consume normal resources. Heroku operates the runtime. - **Northflank Cloud:** The [free, always-on Sandbox](https://northflank.com/pricing) includes two services, one database, and two cron jobs. Pay-as-you-go has no seat fees, meters resources by the second, and currently lists $0.01667 per vCPU-hour, $0.00833 per GB-hour, $0.15 per GB-month of SSD storage, and $0.06 per GB of egress. Enterprise pricing is custom and can include commitments, SLAs, 24/7 support, and onboarding. - **Northflank BYOC:** Your cloud provider bills the underlying infrastructure directly, while Northflank currently charges $0.01389 per vCPU-hour, $0.00139 per GB-hour, and $0.00278 per GB of GPU VRAM-hour. Direct billing preserves applicable cloud credits, reservations, commitments, negotiated rates, and customer capacity choices. Include minimum cluster capacity and retained cloud-account responsibilities in the total cost. - **Total cost:** Model workloads, data, builds, previews, transfer, support, cluster minimums, and engineering time. Northflank may reduce cost when granular allocation, spot capacity, or direct billing outweigh retained responsibility. For Heroku, include dyno, data-service, add-on, Private Space, and applicable contract charges in the total-cost calculation. For a more detailed cost breakdown, see the [Heroku pricing comparison and reduction guide](https://northflank.com/heroku-pricing-comparison-and-reduction), then validate the estimate against your current topology, usage, support requirements, and contract terms. ## When does Heroku fit your requirements? Heroku fits applications that map cleanly to its dyno model and vendor-operated runtime. Heroku does not offer Enterprise Account contracts to new customers. New customers are limited to credit-card billing through the Heroku dashboard. Existing Enterprise subscriptions and support contracts remain honored and may renew as usual. - Your stack maps cleanly to web, worker, one-off, and scheduled dyno processes. - You value buildpacks, Procfile, Pipelines, Review Apps, and the Heroku CLI. - The add-on marketplace covers your data and operational services. - Heroku-operated Common Runtime or Private/Shield Spaces meet your networking, region, compliance, and data-boundary requirements. - You prefer transferring runtime responsibility over controlling Kubernetes or cloud accounts. ## When does Northflank fit your requirements? Northflank fits enterprise and platform teams that need governed developer self-service across broader production workloads and infrastructure environments. - You need one control plane for production full-stack applications, services, jobs, managed data, automated previews, autoscaling, volumes, and optional GPUs. - You want Kubernetes abstraction without making developers operate Kubernetes. - Production workloads must run in your AWS, GCP, Azure, or other supported cloud account, or on eligible public-cloud, on-premises, or bare-metal Kubernetes. - Previews must reproduce private services, jobs, data, volumes, or seed workflows. - You need multi-signal autoscaling plus node-pool, spot, affinity, or placement controls. - Direct cloud-provider billing, existing commitments, specialised compute, or customer VPC data boundaries affect total cost and governance. ## Northflank vs Heroku: final decision Heroku fits teams whose web applications, workers, scheduled tasks, and one-off processes map well to its app-and-dyno model and fully managed runtime. Northflank fits enterprise and platform teams needing governed developer self-service, Kubernetes abstraction, and one control plane for production full-stack applications, services, jobs, managed data, automated previews, autoscaling, workflows, volumes, and optional GPUs across Northflank Cloud, production multi-cloud BYOC, or eligible BYOK. ## Frequently asked questions about Northflank vs Heroku ### What is the main difference between Northflank and Heroku? Heroku runs dyno process types on Heroku infrastructure. Northflank abstracts Kubernetes and runs connected stacks across Northflank Cloud, production BYOC, or eligible BYOK with deeper platform controls. ### Which platform is better for production applications? Heroku fits production applications within its dyno, add-on, networking, and infrastructure model. Northflank fits production applications requiring multi-resource stacks, Kubernetes abstraction, customer-cloud placement, GPUs, or granular controls. ### Which platform is better for Kubernetes and enterprise infrastructure teams? Northflank fits enterprises and platform teams that need governed developer self-service while retaining control over clusters, node pools, resource plans, networking, scheduling, and deployment targets across production BYOC and eligible BYOK. Heroku operates the runtime without exposing Kubernetes-level infrastructure control. Heroku does not offer Enterprise Account contracts to new customers, while existing Enterprise subscriptions and support contracts may renew as usual. ### Does Heroku support Bring Your Own Cloud? Heroku runs dynos in Heroku-operated Common Runtime or Private Spaces. Cedar Private Spaces can peer with a customer-controlled AWS VPC, but that connectivity does not place the Heroku dynos inside the customer's cloud account, so it is not equivalent to Northflank BYOC. ### Can Northflank run in an existing Kubernetes cluster? Yes. Northflank BYOK connects eligible public-cloud, on-premises, or bare-metal clusters that meet its networking, storage, DNS, load-balancer, capacity, and component requirements. A new dedicated cluster is recommended. ### Which platform has better preview environments? Northflank automatically creates full-stack preview environments from pull requests or branch pushes, including services, databases, jobs, volumes, private networking, seed or restore workflows, and unique URLs. Heroku automatically or manually creates disposable Heroku apps for GitHub pull requests, with declared dynos and eligible add-ons billed as normal resources. ### Which platform supports GPU workloads? Northflank directly supports GPU services and jobs on Northflank Cloud and in BYOC GPU node pools. Heroku does not currently offer GPU dynos. ### Which platform is cheaper? Northflank may reduce total cost when per-second allocation, no pay-as-you-go seat fees, spot capacity, or direct cloud billing outweigh cluster minimums and retained responsibility. For Heroku, include dyno, data-service, add-on, Private Space, and applicable contract charges. Compare the complete topology and retained engineering responsibility. ## Related articles about deployment platform selection - [Top Heroku alternatives](https://northflank.com/blog/top-heroku-alternatives) - [Heroku alternatives and how to migrate](https://northflank.com/blog/heroku-alternatives-and-how-to-migrate) - [Why CommonLit moved from Heroku Enterprise to Northflank](https://northflank.com/blog/commonlit-migrated-from-heroku-to-northflank) - [Northflank vs Render](https://northflank.com/blog/northflank-vs-render) - [Northflank vs Railway](https://northflank.com/blog/northflank-vs-railway)

Northflank vs Netlify: which deployment platform should you choose?

2026-08-27T16:53:00.000Z

Netlify provides a web-project deployment model on Netlify-operated infrastructure. Northflank provides a Kubernetes-backed application platform with enterprise governance across Northflank Cloud or your own infrastructure. This comparison covers workloads, developer experience, previews, infrastructure, networking, operations, security, BYOC, pricing, and responsibility. ## TL;DR: Northflank vs Netlify - **Netlify fits web and frontend teams** deploying static, content, ecommerce, and full-stack framework applications. Framework-aware Git builds, global delivery, automatic scaling, collaborative web previews, Functions, Edge Functions, and managed Postgres run on Netlify-operated infrastructure. - **Northflank fits enterprise and platform teams** that need governed developer self-service and one control plane for services, jobs, managed data, full-stack previews, and optional GPUs. Its Kubernetes abstraction spans Northflank Cloud, production BYOC, and BYOK for eligible cloud, on-premises, and bare-metal Kubernetes. Startups and individual engineers can use the same platform. - **The infrastructure boundaries differ.** Netlify operates its runtime. Northflank can operate Kubernetes in your cloud account while your organisation controls its provider relationship, network, capacity, policies, and bill. - **Pricing follows different models.** Netlify combines Free, Personal, Pro, or Enterprise plans with credit-based usage and optional add-ons. Northflank Cloud uses per-second resource pricing; Northflank BYOC combines disclosed platform rates with infrastructure billed directly by your cloud provider. For infrastructure placement or broader workloads, [Northflank](https://northflank.com/) provides developer self-service across [Northflank Cloud](https://northflank.com/features/managed-cloud), [production BYOC and BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements), and [GPU-backed services and jobs](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud). [Northflank Skills](https://github.com/northflank/skills) extend these workflows to coding agents. Platform teams control clusters, networks, resources, and policies without making developers operate Kubernetes. Northflank has [supported production BYOC since 2019](https://northflank.com/blog/is-byoc-the-future-of-software-deployment). [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## Northflank vs Netlify comparison table This table compares the requirements most likely to affect your decision. Product and plan information is current as of 27 August 2026. | Requirement | Northflank | Netlify | | --- | --- | --- | | Best for | Enterprise and platform teams needing governed developer self-service, full-stack previews, autoscaling, Kubernetes abstraction, and one control plane across Northflank Cloud, production BYOC, eligible Kubernetes, and optional GPUs | Web and frontend teams needing framework-aware Git deployment, global delivery, automatic scaling, collaborative web previews, and Netlify-operated infrastructure | | Workload and resource examples | Services and workers; one-off, scheduled, and API-triggered jobs; managed databases, caches, queues, and object storage; volumes; CPU and optional GPU containers | Static and dynamic web projects; Functions; Background and Scheduled Functions; Edge Functions; managed Postgres; Blobs; forms; builds; Agent Runners | | Deployment workflow | Git, Dockerfiles, buildpacks, external images, combined or separate CI/CD, Workflows, templates, GitOps, API, CLI, and JavaScript client | AI-assisted, Git, API, and CLI deployment; framework adapters; atomic deploys; branch deploys; Deploy Previews; deploy contexts | | Infrastructure model | Kubernetes-based platform across Northflank-managed or customer-controlled infrastructure | Web, serverless, edge, and integrated data services on Netlify-operated infrastructure | | BYOC and private infrastructure | Production BYOC across AWS, GCP, Azure, Civo, Oracle Cloud, CoreWeave, and Nebius; BYOK for eligible public-cloud, on-premises, and bare-metal Kubernetes | No documented generally available BYOC offering; Enterprise Private Connectivity links builds and Functions to protected backends | | Data services | Managed databases, caches, queues, object storage, and custom stateful addons with backup, upgrade, scaling, replica, and HA workflows | Managed Postgres with deploy-linked branches; Blobs for unstructured or key-value data; partner integrations | | GPU workloads | Managed-cloud GPU plans and GPU node pools in BYOC for services and jobs | No documented native GPU compute offering; applications can call external AI or GPU services | | Preview environments | Automated full-stack Northflank Preview Blueprints for pull requests or branch pushes, with frontends, services, databases, jobs, volumes, private networking, seed or restore workflows, unique URLs, and configurable cleanup | Automatic web Deploy Previews and branch deploys with collaboration tools and isolated Netlify Database branches | | Private networking | Private networking across services, jobs, databases, and addons; multi-project networking, Tailscale, network policies, configurable routing controls, and workloads inside customer networks through BYOC | Private Connectivity is an Enterprise add-on for controlled outbound access from builds and Functions; it is unavailable for Edge Functions | | Scaling and resource controls | Instance and CPU/memory controls; CPU, memory, RPS, or custom Prometheus autoscaling; BYOC node-pool and scheduling controls | Automatic Function and Edge Function scaling within runtime and plan limits; plan-dependent Function memory controls | | Observability | Build and workload logs and metrics, health checks, alerts, API access, log sinks, and optional network-log forwarding | Request, cache, regional latency, and Function execution visibility; Enterprise log drains | | Security and enterprise | SOC 2 Type 2 and HIPAA compliant; RBAC, SAML/OIDC SSO, directory sync, scoped API access, audit and infrastructure events, workload identities, network controls, HA/DR, 24/7 support, SLAs, and customer-controlled deployment options | SOC 2 Type 2 compliant; plan-dependent roles and audit logs; Enterprise adds SAML SSO, SCIM, organisations, log drains, Private Connectivity, enhanced networking, a HIPAA-compliant offering, and an SLA. | | Pricing model | Free always-on Sandbox; self-service Pay-as-you-go with per-second billing and no seat fees; custom Enterprise pricing; BYOC platform rates plus direct cloud-provider billing | Free, $9 Personal, Pro from $20 with unlimited members, and custom Enterprise; credit-based usage and optional Enterprise add-ons | ## Who are Northflank and Netlify designed for? Netlify centres delivery on a web project. Northflank supports application and infrastructure delivery across a broader mix of applications and workloads. ### Netlify Netlify serves web and frontend teams shipping static, ecommerce, and framework-based applications. Projects combine assets, server-rendered routes, Functions, Edge Functions, forms, Blobs, and managed Postgres. Deploy Previews and the Netlify Drawer support review. The platform fits teams that want Netlify to operate build, runtime, edge delivery, and data infrastructure. It supports production full-stack applications when Functions meet backend requirements, while automatic scaling reduces the need to select instances or manage cluster capacity. ### Northflank Northflank lets enterprise platform, infrastructure, SRE, and security teams give developers self-service without requiring them to operate Kubernetes. Teams can start with a [combined Git-to-deploy service](https://northflank.com/docs/v1/application/getting-started/build-and-deploy-your-code), then separate builds and deployments or use [Workflows](https://northflank.com/docs/v1/application/release/configure-workflows) to coordinate releases, jobs, migrations, addons, and image promotion. Automation options include [templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code), [GitOps](https://northflank.com/docs/v1/application/infrastructure-as-code/gitops-on-northflank), the [API](https://northflank.com/docs/v1/api/use-the-api), [CLI](https://northflank.com/docs/v1/api/use-the-cli), and [JavaScript client](https://northflank.com/docs/v1/api/use-the-javascript-client). [Northflank Skills](https://github.com/northflank/skills) extend them to Codex, Claude Code, Cursor, and other coding agents, governed by credentials, RBAC, and audit controls. Northflank provides a unified control plane for services, jobs, managed data, automated full-stack previews, autoscaling, and optional GPU workloads. Enterprises, startups, and individual engineers use the same developer workflow. ## What are the main differences between Northflank and Netlify? The main differences are workload model, infrastructure ownership, preview scope, and the level at which teams control resources and operations. ### Application, workload, and data support Netlify packages a web application as a project with atomic deploys. Dynamic logic runs through synchronous Functions, Scheduled Functions, Background Functions, or Edge Functions. Synchronous Functions have a 60-second execution limit, Scheduled Functions 30 seconds, and Background Functions 15 minutes. Edge Functions allow 50 ms of CPU execution per request. Functions default to 1 GB memory; credit-based Pro and Enterprise plans can configure up to 4 GB. Netlify Database provides managed Postgres with deploy-integrated branches and migrations. Blobs supports unstructured data and key-value use cases. These are not persistent-container or Kubernetes Job runtimes. Northflank runs arbitrary images as persistent services or workers. Jobs run once, on a schedule, or through an API trigger for migrations, batch processing, maintenance, and ML tasks. [Managed addons](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank) provide databases, caches, queues, and object storage with backup, upgrade, scaling, replica, and HA workflows; volumes support custom stateful software. Northflank runs [GPU-backed services and jobs](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud) on managed GPU plans or customer-cloud nodes. Netlify has no documented native GPU compute offering, but applications can call external GPU services. ### Deployment workflow and preview environments Netlify centres deployment on framework adapters, atomic deploys, and Deploy Previews. Pull or merge requests create previews with unique URLs and collaboration tools. Application rollback does not automatically restore a production database branch. Northflank provides [direct Git-to-deploy](https://northflank.com/docs/v1/application/getting-started/build-and-deploy-your-code). [Dockerfiles](https://northflank.com/docs/v1/application/build/build-with-a-dockerfile), [buildpacks](https://northflank.com/docs/v1/application/build/build-with-buildpacks), and [external registries](https://northflank.com/docs/v1/application/run/run-an-image-from-a-container-registry) supply images. Separate CI/CD and [Workflows](https://northflank.com/docs/v1/application/release/configure-workflows) coordinate services, jobs, addons, migrations, and image promotion. [Northflank Preview Blueprints](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) reproduce complete application stacks, including frontends, services, databases, jobs, volumes, private networking, seed or restore workflows, and unique URLs. Configurable cleanup rules can remove the environment when its pull request closes or merges. ### Infrastructure, Bring Your Own Cloud (BYOC), and Bring Your Own Kubernetes (BYOK) Netlify operates its build, delivery, serverless, edge, and data infrastructure. Enterprise Private Connectivity provides stable outbound IPs, and Netlify can configure a dedicated VPC for Functions. This is connectivity rather than customer-account BYOC and excludes Edge Functions. [Northflank Cloud](https://northflank.com/features/managed-cloud) provides managed container infrastructure. The same application abstractions extend to Bring Your Own Cloud (BYOC) and Bring Your Own Kubernetes (BYOK). Northflank has supported production BYOC since 2019, provisioning and managing Kubernetes in [AWS](https://northflank.com/cloud/aws), [GCP](https://northflank.com/cloud/gcp), [Azure](https://northflank.com/cloud/azure), [Civo](https://northflank.com/cloud/civo), [Oracle Cloud](https://northflank.com/cloud/oci), [CoreWeave](https://northflank.com/cloud/coreweave), or [Nebius](https://northflank.com/cloud/nebius). You own the account, provider relationship, bill, capacity, and cloud controls; Northflank manages the provisioned cluster and application control plane. [Northflank BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements) imports an eligible existing public-cloud, on-premises, or bare-metal Kubernetes cluster. A BYOC or BYOK cluster requires at least 12 vCPU and 24 GB in total. BYOC supports a minimum of one node, while BYOK requires at least three nodes; each node must provide at least 4 vCPU and 8 GB of memory. ### Private networking, scaling, and observability Northflank [private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank) connects services, jobs, databases, and addons through private ports, with multi-project networking, Tailscale, network policies, and configurable routing controls. In BYOC, workloads run inside the customer's VPC or network and inherit its routing, firewalls, private endpoints, and connectivity architecture. Netlify Private Connectivity is an Enterprise add-on requiring High-Performance Edge or High-Performance Build. It gives builds and standard Functions a specific set of outbound IP addresses to allowlist in supported regions, but it does not apply to Edge Functions. Standard Functions and Edge Functions scale automatically within their respective runtime and plan limits. Northflank lets teams [set instance counts](https://northflank.com/docs/v1/application/scale/scale-instances), choose CPU and memory, or [autoscale deployments](https://northflank.com/docs/v1/application/scale/autoscale-deployments) using CPU, memory, requests per second, or custom Prometheus metrics. BYOC adds [custom resource plans](https://northflank.com/docs/v1/application/bring-your-own-cloud/create-custom-resource-plans), [spot nodes](https://northflank.com/docs/v1/application/bring-your-own-cloud/deploy-and-scale-node-pools), [workload affinity](https://northflank.com/docs/v1/application/bring-your-own-cloud/deploy-workloads-to-your-cluster), [separate build capacity](https://northflank.com/docs/v1/application/bring-your-own-cloud/configure-your-cluster), [node-pool scaling](https://northflank.com/docs/v1/application/bring-your-own-cloud/deploy-and-scale-node-pools), and [placement controls](https://northflank.com/docs/v1/application/bring-your-own-cloud/deploy-workloads-to-your-cluster). Netlify Observability covers requests, cache status, regional latency, and Function execution; Enterprise log drains export traffic, Function, Edge Function, deploy, and WAF logs. Northflank exposes [build and workload logs](https://northflank.com/docs/v1/application/observe/view-logs), [metrics](https://northflank.com/docs/v1/application/observe/view-metrics), [health checks](https://northflank.com/docs/v1/application/observe/configure-health-checks), [alerts](https://northflank.com/docs/v1/application/observe/set-infrastructure-alerts), and [API access](https://northflank.com/docs/v1/api/use-the-api). [Log sinks](https://northflank.com/docs/v1/application/observe/configure-log-sinks) forward runtime and optional network logs. Application traces and business telemetry require instrumentation on either platform. ## Which security and enterprise controls do Northflank and Netlify provide? Both support enterprise identity, access, audit, compliance, and support, with different packaging and infrastructure boundaries. Netlify provides plan-dependent roles and audit logs. Enterprise adds SAML SSO, SCIM, organisations, log drains, Private Connectivity, enhanced networking, and 24/7 support. Buyers should confirm SLA coverage, compliance requirements, and contract terms. Northflank provides [granular RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [scoped API access](https://northflank.com/docs/v1/application/secure/grant-api-access), [SAML or OIDC SSO](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation#configure-single-sign-on-sso), [directory sync](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation#sync-your-directory), [MFA](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication), [secrets](https://northflank.com/docs/v1/application/secure/manage-secret-groups), [network controls](https://northflank.com/docs/v1/application/network/configure-network-policies), [workload identities](https://northflank.com/docs/v1/application/enterprise), [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs), and [infrastructure events](https://northflank.com/docs/v1/application/enterprise). Enterprise adds HA/DR, 24/7 support, SLAs, and customer-VPC, on-premises, forward-deployed, or air-gapped options. Forward-deployed control planes require specific spend thresholds or an arrangement. Northflank is SOC 2 Type 2 and HIPAA compliant, with BAAs supported under Enterprise contracts. It also supports cloud-account ownership, Kubernetes governance, private deployment, and customer-controlled networks. ## How do Northflank and Netlify compare on pricing and operational responsibility? Netlify combines plan tiers with credit-based usage. Northflank offers transparent usage-based pricing for Northflank Cloud. With Northflank BYOC, you pay your cloud provider directly for infrastructure, preserving applicable cloud credits, commitments, reservations, and negotiated rates. Prices were checked on 27 August 2026. - **Netlify:** Netlify's credit-based plans include Free with 300 monthly credits, Personal at $9 with 1,000 credits, and Pro from $20 with 3,000 credits and unlimited members. Pro tiers scale up to 20,000 credits; Enterprise pricing is custom. Credits meter production deploys, compute, bandwidth, web requests, AI inference, and Netlify Database usage. Private Connectivity is an Enterprise add-on. - **Northflank:** The free Sandbox includes always-on compute, two services, one database, and two cron jobs. [Pay-as-you-go](https://northflank.com/pricing) is self-service, has no seat fees, and bills per second. Northflank Cloud costs $0.01667 per vCPU-hour and $0.00833 per GB-hour, plus storage and networking. Enterprise adds invoice billing, volume discounts, annual commitments, 24/7 support, and SLAs. In BYOC, the cloud provider bills infrastructure directly while Northflank charges $0.01389 per vCPU-hour, $0.00139 per GB-hour, and $0.00278 per GB of GPU VRAM-hour. Direct billing preserves cloud credits, reservations, commitments, negotiated rates, and customer capacity choices. - **Total cost of ownership:** Include plans, compute, requests, transfer, storage, data, previews, support, cloud charges, BYOC minimum capacity, and retained engineering work. Netlify operates its runtime; Northflank abstracts Kubernetes while BYOC customers retain cloud-account and capacity decisions. Compare a representative topology. ## When does Netlify fit your requirements? Netlify fits applications using its web-project model and infrastructure. - Your product is a static, content, ecommerce, or framework-based web application. - Framework-aware builds, atomic application deploys, web previews, and stakeholder collaboration are central to delivery. - Functions, Background Functions, Scheduled Functions, Edge Functions, Postgres, and Blobs cover the application architecture within their limits. - Global delivery, automatic scaling, analytics, and web observability meet your requirements. - Netlify-managed regions, Private Connectivity options, security controls, and commercial terms fit your residency and procurement requirements. ## When does Northflank fit your requirements? Northflank fits enterprise and platform teams delivering a broader production stack across managed or customer-controlled infrastructure. - You run persistent services, workers, independent jobs, managed data, volumes, or optional GPU containers. - Full-stack previews must create services, databases, jobs, volumes, private networks, data workflows, and URLs together. - You need production BYOC across supported clouds, eligible existing Kubernetes through BYOK, or qualified on-premises or bare-metal infrastructure. - Developers should not need to operate Kubernetes, while platform teams retain cluster, resource, scheduling, network, and policy controls. - You want a consistent control plane and developer workflow across Northflank Cloud and customer-controlled infrastructure. - Cloud commitments, specialised compute, data residency, direct cloud-provider billing, or capacity utilisation affect the operating model and total cost. ## Northflank vs Netlify: final decision Netlify fits web-first applications using framework-aware builds, previews, Functions, automatic scaling, and Netlify-operated infrastructure. Northflank fits platform and enterprise teams needing governed developer self-service, Kubernetes abstraction, and one control plane for production full-stack applications, services, jobs, managed data, automated previews, autoscaling, and optional GPUs across Northflank Cloud, multi-cloud BYOC, and BYOK. Before choosing, test a representative application and preview environment, validate private connectivity, and model monthly costs against your required infrastructure ownership boundary. ## Frequently asked questions about Northflank vs Netlify ### Is Northflank better than Netlify? Northflank fits production full-stack applications, mixed workloads, managed data, optional GPUs, automated full-stack previews, multi-cloud BYOC, and teams that do not want developers operating Kubernetes. Netlify fits web applications needing framework-aware builds, automatic scaling, and web-focused Deploy Previews with built-in collaboration tools. ### Is Netlify only for static sites? No. Netlify supports dynamic web applications through framework adapters, multiple Function types, managed Postgres, and Blobs. Its core model is a web project rather than a persistent-container or Kubernetes Job platform. ### Does Netlify support BYOC? Netlify has no documented generally available BYOC offering. Enterprise Private Connectivity provides stable outbound IPs and a dedicated VPC option for Functions, connecting Netlify workloads to protected systems rather than deploying into the customer's account. ### Which platform is better for preview environments? Northflank automatically creates full-stack preview environments from pull requests or branch pushes, including services, databases, jobs, volumes, private networking, seed or restore workflows, and unique URLs. Netlify automatically creates web-focused Deploy Previews with deploy-specific URLs, collaboration tools, and isolated Postgres branches when Netlify Database is used. ### Which platform is better for enterprise teams? Northflank fits enterprises that need governed developer self-service, Kubernetes abstraction, and one control plane for production full-stack workloads across Northflank Cloud, BYOC, and BYOK, with control over clusters, resources, networking, scheduling, managed data, and optional GPUs. Netlify fits enterprises standardising framework-aware web delivery, collaborative Deploy Previews, and serverless or edge functions on Netlify-operated infrastructure. ### Which is cheaper, Northflank or Netlify? Pricing depends on workload and operating model. Netlify combines plans with usage credits. Northflank uses per-second pricing without pay-as-you-go seat fees; BYOC adds platform rates to the cloud bill. ## Related articles about deployment platform selection - [Netlify alternatives](https://northflank.com/blog/netlify-alternatives) - [Vercel vs Netlify](https://northflank.com/blog/vercel-vs-netlify-choosing-the-deployment-platform-in-2026) - [Best preview environment platforms](https://northflank.com/blog/preview-environment-platforms) - [What is the best PaaS that can run in my own cloud account?](https://northflank.com/blog/best-paas-that-runs-in-my-own-cloud-account-bypc-self-hosted-paas) - [Best cloud app deployment platforms](https://northflank.com/blog/best-cloud-app-deployment-platforms)

How to manage SaaS deployments across customer VPCs at scale

2026-08-27T15:45:00.000Z

### TL;DR: how to manage SaaS deployments across customer VPCs - **Automate onboarding and upgrades:** Use templates, versioning, and rollout controls to manage customer environments consistently. - **Control drift and operations:** Track configuration changes, monitor fleet health, and prepare incident response workflows across account boundaries. - **Use a fleet management layer:** A centralized control plane can manage deployments across customer VPCs without requiring your team to operate each environment individually. > [Northflank](https://northflank.com/product/customer-vpc-deployments) provides a fleet management layer for SaaS vendors deploying across [customer environments](https://northflank.com/product/customer-vpc-deployments), helping teams automate onboarding and deployments with repeatable templates, manage versions and customer-specific configuration, and maintain centralized visibility across distributed environments. Teams can manage customer deployments across AWS, GCP, Azure, Oracle, and on-premises from a single control plane while keeping workloads in customer-controlled infrastructure. [Get started](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > Getting the first customer VPC deployment running is an engineering achievement. You have provisioned infrastructure in a customer's cloud account, established cross-account connectivity, deployed your application, and handed over a working environment. That milestone feels like the hard part. The harder problem comes next: fifteen customer environments in production, each needing updates on different schedules, each with configuration variations from the original template, each generating its own operational signals across account boundaries, and a growing queue of new customers waiting to onboard. At that point, the deployment model you built for one customer starts to show its limitations, and the gap between “we can deploy into customer VPCs” and “we can operate a fleet of customer VPC deployments” becomes impossible to ignore. ## What changes when you manage SaaS across multiple customer environments A single customer VPC deployment is a project. A fleet of them is a product. As the number of customer environments grows, the operational requirements change. - **Onboarding becomes an automation problem:** Manually provisioning each customer environment does not scale. Templates and automated provisioning make onboarding repeatable. - **Versioning becomes a coordination problem:** Customers may need different upgrade schedules, approval processes, or versions. You need controlled rollouts and a way to track version differences across the fleet. - **Configuration drift accumulates:** Customer environments that started with the same template can diverge due to configuration changes, patches, and customer-specific requirements. Without tracking desired and actual state, drift can surface unexpectedly during upgrades. - **Observability must cross account boundaries:** You need fleet-level visibility into service health, errors, latency, and resource usage without accessing customer application data. This requires a clear separation between operational telemetry and customer data. - **Incident response needs to work across environments:** Your team needs to detect issues, access the right environment, and apply fixes without treating every customer deployment as a separate operational system. The rest of the challenge is turning these requirements into repeatable operational processes across the fleet. > For background on why enterprises require customer-hosted deployments, the different deployment models, and how the control plane and application plane are separated, see [SaaS deployment in customer environments](https://northflank.com/blog/saas-deployment-in-customer-environment). > ## Onboarding new customer environments Onboarding a customer VPC involves provisioning infrastructure, enabling cross-account access, deploying applications, configuring customer-specific settings, and conducting acceptance testing. Doing this manually does not scale, so the process should be repeatable and automated. - **Use templated provisioning:** Define the desired customer environment once, including infrastructure, networking, access roles, and application configuration. Parameterize customer-specific values such as account ID, region, domain, and feature configuration, then provision each environment from the same template. - **Automate cross-account access:** Use least-privilege roles or identities to give your control plane the access it needs for deployment and monitoring. Providing customers with ready-made Terraform modules or cloud templates can also simplify their security review and setup. - **Automate acceptance testing:** Verify that the application is reachable, core functionality works, monitoring signals are flowing, and the environment is visible in your fleet management system before marking it production-ready. > If you are still designing the initial customer VPC deployment, see our guide to [how to deploy SaaS in a customer VPC](https://northflank.com/blog/deploy-saas-in-customer-vpc) for the main implementation approaches and their tradeoffs. > ## Managing versions and coordinated upgrades Once you have multiple customer environments, releasing a new application version becomes a fleet coordination problem. - **Use progressive rollouts:** Start with a small canary group, then expand to early-access and standard customer rings once the release has proven stable. - **Support per-customer approval:** Some customers need to approve production changes before an upgrade. Your deployment workflow should allow updates to be staged until the customer gives approval. - **Manage version skew:** Customers will inevitably run different versions. Define a supported version window and a clear upgrade path for customers running older releases. - **Keep rollback available:** Track the deployed version for each customer environment so you can quickly return to the previous version when an upgrade causes problems. ## Detecting and managing configuration drift Customer environments that start from the same template can diverge over time through manual changes, customer-specific configuration, patches, or incident fixes. - **Track desired and observed state:** Compare the configuration defined for each customer with the state actually running in their environment to identify unexpected differences. - **Separate intentional changes from drift:** Store customer-specific configuration as explicit, version-controlled overrides. Differences outside those overrides can then be treated as drift. - **Reconcile automatically where possible:** GitOps tools can continuously reconcile Kubernetes resources with their desired state, while infrastructure and configuration management can handle drift outside the cluster. ## Observability across the SaaS fleet Fleet operations require visibility into customer environments without crossing the data boundaries that customer VPC deployments are designed to preserve. - **Collect operational telemetry:** Monitor service health, error rates, latency, resource utilization, and other infrastructure signals across customer environments. - **Keep customer data isolated:** Application data, database contents, and logs containing sensitive customer information should remain within the customer's environment unless explicitly permitted. - **Create a fleet-level health view:** Aggregate operational signals into a single view so your team can quickly identify unhealthy environments and spot issues affecting multiple customers, regions, or cloud providers. - **Alert proactively:** Route environment health signals to your on-call team so problems can be detected before customers have to report them. ## Incident response across customer environments Customer VPC incidents add another challenge: the access needed to investigate an incident may be more privileged than the access required for normal operations. - **Pre-authorize incident access:** Define a separate, audited break-glass role for elevated incident access rather than granting broad permissions to the normal deployment role. - **Maintain environment-specific runbooks:** Record customer-specific configurations, network constraints, escalation contacts, and other information your team needs to investigate incidents quickly. - **Support targeted fixes:** Allow emergency fixes to be deployed to a single customer environment and record the change so it is not accidentally overwritten by the next fleet-wide upgrade. ## Regional and multi-cloud operations Enterprise customers may run your application across different clouds, regions, or their own infrastructure, adding another layer of operational complexity. - **Maintain a consistent deployment model:** Abstract cloud-specific authentication, networking, and infrastructure differences so the application and fleet management workflows remain consistent. - **Respect data residency:** Consider where application data and operational telemetry are stored, particularly for customers with geographic or regulatory requirements. - **Account for cloud-specific behavior:** Your fleet tooling and operational runbooks need to handle differences across AWS, GCP, Azure, and on-premises environments. ## How Northflank manages SaaS deployments at scale [Northflank](https://northflank.com/) provides a control plane for teams that need to deploy and operate applications across distributed customer environments. Instead of building separate tooling for provisioning, deployments, infrastructure management, and customer environments, teams can use Northflank to manage these workflows through a single platform. Key capabilities include: - [**Customer environment deployment**](https://northflank.com/product/customer-vpc-deployments): deploy applications and infrastructure into customer environments using repeatable configurations. - **Centralized fleet management:** manage distributed deployments from a single control plane rather than operating each customer environment independently. - **Deployment management:** build and deploy new application versions while maintaining visibility into deployment state across environments. - **Environment-specific configuration:** apply customer-specific settings while keeping the underlying deployment model consistent. - [**Bring your own cloud (BYOC)**](https://northflank.com/product/bring-your-own-cloud): run workloads in customer-controlled or your own cloud infrastructure across AWS, GCP, Azure, and other supported environments. - [**Enterprise governance**](https://northflank.com/enterprise): use RBAC, SSO, and audit logging to control access to platform operations. - [**Infrastructure visibility**](https://northflank.com/docs/v1/application/observe/observability-on-northflank): monitor deployments and infrastructure across customer environments without requiring the platform team to manage each environment individually. - **Multi-region and multi-cloud operations:** manage deployments across different regions and infrastructure providers through the same platform. For SaaS vendors, the goal is not to eliminate differences between customer environments. Those differences are often necessary. The goal is to make them **explicit, manageable, and observable** without turning every customer deployment into a bespoke infrastructure project. Northflank provides the control plane for this model, allowing teams to manage a growing fleet of customer environments while keeping customer-specific infrastructure and configuration requirements intact. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your fleet management requirements. ## Conclusion Managing a SaaS fleet across customer VPCs is different from deploying into a single customer environment. As the fleet grows, onboarding, versioning, configuration drift, observability, incident response, and regional operations all need to be managed systematically. A fleet management layer provides the abstraction needed to manage these environments consistently, without treating every customer deployment as a separate infrastructure project. [Northflank](https://northflank.com/product/customer-vpc-deployments) provides this control plane, helping SaaS vendors manage distributed customer environments while keeping their focus on the product. ## **FAQ:** how to manage SaaS deployments across customer VPCs ### What is SaaS fleet management? SaaS fleet management is the practice of managing multiple distributed customer deployments as a single operational fleet. It covers provisioning, configuration, version management, upgrades, observability, incident response, and infrastructure operations. ### How do you manage SaaS deployments across multiple customer VPCs? Use repeatable infrastructure and application templates, centralized deployment management, explicit customer-specific configuration, fleet-wide observability, and controlled access to each customer environment. ### How do you handle SaaS upgrades across customer environments? Track the version running in each environment and use progressive rollout strategies such as canary deployments, deployment rings, and customer approval gates. This allows customers to upgrade at different times while keeping the fleet within a supported version range. ### How do you prevent configuration drift in customer deployments? Define a desired state for each environment, compare it against the observed state, and explicitly distinguish approved customer-specific configuration from unexpected changes. Drift can then be reconciled automatically or reviewed manually depending on the resource. ### How do you monitor SaaS deployments in customer environments? Centralize operational health signals such as deployment status, service health, infrastructure metrics, and error rates while respecting the customer's data boundary. This provides fleet-level visibility without requiring customer application data to leave their environment. ## Related Articles - [How to deploy SaaS in a customer VPC](https://northflank.com/blog/deploy-saas-in-customer-vpc) - [SaaS deployment in a customer environment](https://northflank.com/blog/saas-deployment-in-customer-environment) - [What is BYOC in cloud computing?](https://northflank.com/blog/what-is-byoc-in-cloud-computing)

Northflank vs Vercel: which platform should you choose?

2026-08-26T16:40:00.000Z

Northflank fits teams that need developer self-service across a broad production stack, including container services, jobs, managed data, GPUs, and Kubernetes infrastructure. Vercel fits frontend-led teams that want a framework-aware path from Git to globally delivered web applications. This comparison covers workloads, developer experience, previews, infrastructure, networking, scaling, observability, security, Bring Your Own Cloud (BYOC), pricing, and operational responsibility. ## TL;DR: Northflank vs Vercel - **Northflank fits enterprise and platform teams running a broader production stack.** Its Kubernetes abstraction gives developers self-service delivery for services, jobs, managed data, previews, and optional GPUs while infrastructure teams retain control over networks, resources, clusters, and policies. - **Vercel fits teams building frontend-led web products, particularly with Next.js.** Its framework-aware builds, global delivery, Functions, automatic scaling, and collaborative previews reduce the infrastructure decisions required to ship web applications. - **Both have a BYOC story, but their maturity and scope differ.** Vercel BYOC runs in a customer's AWS account and is in private beta. Northflank has supported production BYOC since 2019 across multiple cloud providers, with BYOK for eligible existing Kubernetes, including on-premises and bare metal. - **Pricing reflects different operating models.** Vercel combines a platform fee, deploying seats, usage, and optional add-ons. Northflank Cloud uses granular usage pricing; Northflank BYOC combines transparent platform rates with infrastructure billed directly by your cloud provider. For infrastructure placement or broader workloads, [Northflank](https://northflank.com/) provides governed developer self-service and Kubernetes abstraction across [Northflank Cloud](https://northflank.com/features/managed-cloud), established [production BYOC and BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements), and [GPU-backed services and jobs](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud). [Northflank Skills](https://github.com/northflank/skills) extend these workflows to coding agents. Platform teams control clusters, networks, resources, and policies without making developers operate Kubernetes. Northflank has [supported production BYOC since 2019](https://northflank.com/blog/is-byoc-the-future-of-software-deployment). [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## Northflank vs Vercel comparison table This table compares the requirements most likely to affect your decision. Product and plan information is current as of 26 August 2026. | Requirement | Northflank | Vercel | | --- | --- | --- | | Best for | Enterprise and platform teams needing governed developer self-service, full-stack previews, autoscaling, Kubernetes abstraction, and one control plane across managed cloud, production BYOC, eligible Kubernetes, and optional GPUs | Frontend and web teams needing framework-aware Git deployments, global delivery, automatic Fluid scaling, collaborative web previews, and a vendor-managed runtime centered on Vercel Functions. | | Workloads | Services, workers, one-off, scheduled, and API-triggered jobs, managed addons, volumes, and CPU or GPU containers. | Web applications, Functions, Cron Jobs, durable Workflows, Blob, Edge Config, and Marketplace data services | | Deployment | Git, Dockerfiles, buildpacks, external images, separate CI/CD, Workflows, templates, GitOps, API, and CLI | Git, framework presets, CLI, Deploy Hooks, API, immutable deployments, rollback, and microfrontends tooling | | Infrastructure | Northflank Cloud, provisioned Kubernetes in your cloud account, or eligible existing Kubernetes | Vercel-managed global platform; AWS BYOC is in private beta | | BYOC and BYOK | Production BYOC across AWS, GCP, Azure, Civo, Oracle, CoreWeave, and Nebius; BYOK for eligible cloud, on-premises, and bare-metal Kubernetes | AWS BYOC in private beta; Vercel operates the control plane | | Data and GPUs | Managed databases, caches, queues, object storage, custom stateful addons, and GPU-backed services or jobs | Blob, Edge Config, Marketplace data services, and CPU/memory-based Functions | | Previews | Full-stack Preview Blueprints with services, jobs, databases, volumes, networking, seed workflows, and URLs | Automatic web previews with branch or commit URLs, comments, sharing, and protection | | Private networking | Private networking across services, jobs, databases, and addons; multi-project networking, Tailscale, network policies, and workloads running inside your VPC or network through BYOC. | Secure Compute is a paid Enterprise add-on providing an isolated runtime network, dedicated outbound IPs, and VPC peering; separate Static IPs are available on Pro and Enterprise. | | Scaling | Horizontal and vertical scaling; CPU, memory, RPS, or custom-metric autoscaling; BYOC node-pool controls | Automatic Fluid scaling with configurable Function memory, duration, and region within plan limits | | Observability | Build and workload logs and metrics, alerts, API access, and log sinks | Deployment, traffic, Function, build, and cost insights; Observability Plus and Drains | | Enterprise controls | SOC 2 Type 2 and HIPAA compliant; RBAC, SAML/OIDC SSO, directory sync, scoped API access, audit events, workload identities, HA/DR, 24/7 support, SLAs, and customer-controlled deployment options | SOC 2 Type 2 and PCI DSS attestations; ISO 27001 certified; roles, SAML SSO, Directory Sync, audit logs, Deployment Protection, WAF, Secure Compute, SIEM integration, and SLAs | | Pricing | Free always-on Sandbox; self-service Pay-as-you-go with per-second billing and no seat fees; custom Enterprise pricing; BYOC platform rates plus direct cloud-provider billing. | Free non-commercial Hobby; Pro at $20/month with one deploying seat and $20 usage credit, plus usage, seats, and add-ons; custom Enterprise pricing. | ## Who are Northflank and Vercel designed for? Vercel centers the web application delivery lifecycle. Northflank supports application and infrastructure delivery across a broader production stack. ### Vercel Vercel is well suited to frontend teams shipping Next.js and other framework-based web applications. Connecting a repository detects the framework, builds the project, deploys static assets globally, creates Functions where needed, and gives each deployment a URL. Vercel also supports APIs, multi-tenant SaaS, microfrontends, and AI applications. Fluid compute reuses Function capacity before scaling out, without requiring teams to operate runtime nodes. ### Northflank Northflank lets platform, infrastructure, SRE, and security teams provide governed developer self-service without requiring application teams to operate Kubernetes directly. Developers can begin with a [combined Git-to-deploy service](https://northflank.com/docs/v1/application/getting-started/build-and-deploy-your-code), then separate builds and deployments, coordinate releases with [Workflows](https://northflank.com/docs/v1/application/getting-started/set-up-environments), or automate resources through [templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code), [GitOps](https://northflank.com/docs/v1/application/infrastructure-as-code/gitops-on-northflank), the [API](https://northflank.com/docs/v1/api/use-the-api), or [CLI](https://northflank.com/docs/v1/api/use-the-cli). Teams can extend these interfaces into AI-assisted workflows with [Northflank Skills](https://github.com/northflank/skills) for Codex, Claude Code, Cursor, and other coding agents, with actions governed by API or CLI credentials, RBAC, and audit controls. The same control plane covers applications, workers, jobs, databases, queues, previews, and optional GPUs. Growing startups and individual engineers can use the same self-service workflow. ## What are the main differences between Northflank and Vercel? The main differences are workload breadth, infrastructure ownership, and the level at which teams control resources and operations. ### Application and workload support Northflank runs arbitrary container images as persistent services or workers. Jobs can run once, on a schedule, or through an API trigger for migrations, batch processing, maintenance, and ML tasks. [Managed addons](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank) provide databases, caches, queues, and object storage with backup, upgrade, scaling, replica, and HA workflows. Volumes support custom stateful software, while [GPU-backed services and jobs](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud) can use managed GPU plans or customer-cloud GPU nodes. Vercel maps applications onto globally delivered web output and request-driven Functions. Cron Jobs invoke Functions rather than providing a separate batch runtime. Vercel Workflows provides durable asynchronous JavaScript that can suspend, resume, and preserve state without a workflow-level timeout, but it is not a general persistent-container or Kubernetes Job runtime. Vercel provides Blob and Edge Config. Postgres, Redis, NoSQL, vector databases, and queues come from Marketplace providers such as Neon, Supabase, MongoDB Atlas, and Upstash. ### Deployment workflow and preview environments Vercel creates an immutable deployment for a Git push and a shareable preview for a pull request. Its preview workflow is oriented toward web review, with automatic branch- and commit-specific URLs, comments, sharing, access protection, a development toolbar, and framework-aware behavior. Vercel also provides monorepo optimization and first-party microfrontends routing. Northflank provides [direct Git-to-deploy](https://northflank.com/docs/v1/application/getting-started/build-and-deploy-your-code) while exposing more release control when required. [Dockerfiles](https://northflank.com/docs/v1/application/build/build-with-a-dockerfile), [buildpacks](https://northflank.com/docs/v1/application/build/build-with-buildpacks), and [external registries](https://northflank.com/docs/v1/application/run/run-an-image-from-a-container-registry) supply images. Separate build and deployment services support independent CI and CD, while [Workflows](https://northflank.com/docs/v1/application/release/configure-workflows) coordinate services, jobs, and addons. [Northflank Preview Blueprints](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) can reproduce complete application stacks, including frontends, services, databases, jobs, volumes, private networking, seed data, and unique URLs. ### Infrastructure, BYOC, and BYOK Vercel operates its standard global platform and runtime. Its AWS BYOC private beta places compute, build artifacts, and data in the customer's AWS account and VPC while Vercel operates the control plane. This can fit enterprises that need existing AWS identity, network, and audit controls, but availability and commercial terms remain private-beta dependent. [Northflank Cloud](https://northflank.com/features/managed-cloud) provides managed infrastructure for container workloads. Northflank uses the same application abstractions across its cloud and Kubernetes connected through Bring Your Own Cloud (BYOC) or Bring Your Own Kubernetes (BYOK). Developers work with services, jobs, addons, and environments while platform teams retain node-pool, resource, scheduling, networking, and observability controls. Northflank has supported production BYOC since 2019. It provisions and manages Kubernetes in your [AWS](https://northflank.com/cloud/aws), [GCP](https://northflank.com/cloud/gcp), [Azure](https://northflank.com/cloud/azure), [Civo](https://northflank.com/cloud/civo), [Oracle Cloud](https://northflank.com/cloud/oci), [CoreWeave](https://northflank.com/cloud/coreweave), or [Nebius](https://northflank.com/cloud/nebius) account. Your organization owns the account, provider relationship, bill, capacity, and cloud controls. [Northflank BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements) imports an eligible existing public-cloud, on-premises, or bare-metal Kubernetes cluster. Northflank requires at least 12 vCPU and 24 GB per BYOC or BYOK cluster; BYOC permits one node, while BYOK requires three. ### Private networking, scaling, and observability Northflank [private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank) connects services, jobs, databases, and addons through private ports, with multi-project networking and Tailscale. In BYOC, workloads run inside the customer's network and inherit its routing, firewalls, private endpoints, and connectivity architecture. Vercel Secure Compute gives Enterprise customers an isolated runtime network with dedicated outbound IPs and VPC peering. Static IPs on Pro and Enterprise provide stable shared-network egress for allowlisting public endpoints; they do not create a private route to an internal-only network. Vercel automatically scales Functions through Fluid compute; teams configure memory, duration, and region within plan limits without managing runtime nodes. Northflank lets teams [set instance counts](https://northflank.com/docs/v1/application/scale/scale-instances), select CPU and memory, or [autoscale deployments](https://northflank.com/docs/v1/application/scale/autoscale-deployments) using CPU, memory, requests per second, or custom Prometheus metrics. BYOC adds custom plans, spot nodes, workload affinity, separate build capacity, and node-pool scaling. Northflank exposes logs and metrics across builds, services, jobs, databases, and addons. [Log sinks](https://northflank.com/docs/v1/application/observe/configure-log-sinks) forward runtime and optional network logs. Vercel Observability covers traffic, Functions, builds, deployments, and cost signals; Observability Plus adds capabilities and retention, while Pro and Enterprise Drains export logs, OpenTelemetry traces, Web Analytics, and Speed Insights data. Application traces require instrumentation on either platform. ## Which security and enterprise controls do Northflank and Vercel provide? Both platforms support enterprise identity, access, audit, and compliance requirements, but they differ in feature packaging and infrastructure ownership. Vercel Enterprise includes roles, SAML SSO, Directory Sync, audit logs, Deployment Protection, managed WAF rules, and a 99.99% SLA. Secure Compute and SIEM integration are paid Enterprise add-ons; Pro can purchase SAML SSO and a HIPAA BAA. Vercel has SOC 2 Type 2 and PCI DSS attestations, ISO 27001 certification, and support for HIPAA compliance. Northflank provides [granular RBAC and scoped API access](https://northflank.com/docs/v1/application/secure/security-on-northflank), SAML or OIDC SSO, directory sync, MFA enforcement, secrets, and audit events. Enterprise adds 24/7 support and SLAs, global backups and HA/DR, and runtime options in your VPC, on-premises, forward-deployed, or air-gapped environments. Northflank is SOC 2 Type 2 and HIPAA compliant, with BAAs supported under Enterprise contracts. ## How do Northflank and Vercel compare on pricing and operational responsibility? Vercel combines a platform fee, deploying seats, usage, and optional charges. Northflank separates managed-cloud consumption or BYOC platform fees from the customer's infrastructure bill. Prices were checked on 26 August 2026. - **Vercel:** Hobby is free for personal, non-commercial use. Pro costs $20 per month, includes one deploying seat and $20 usage credit, and bills additional usage on demand. Extra deploying seats cost $20 per month; Viewer seats are free. Enterprise is custom-priced. Pro lists SAML SSO at $300 per month and a HIPAA BAA at $350 per month. - **Northflank:** The free Sandbox includes always-on compute, two services, one database, and two cron jobs. [Pay-as-you-go](https://northflank.com/pricing) has no seat fees and bills per second. Northflank Cloud costs $0.01667 per vCPU-hour and $0.00833 per GB-hour, plus storage and networking. Enterprise adds invoice billing, volume discounts, annual commitments, 24/7 support, and SLAs. In BYOC, the cloud provider bills infrastructure directly while Northflank charges $0.01389 per vCPU-hour, $0.00139 per GB-hour, and $0.00278 per GB of GPU VRAM-hour. Direct billing preserves cloud credits, commitments, and negotiated rates. - **Total cost:** Include seats, builds, requests, data transfer, storage, networking, previews, support, cloud-provider charges, minimum capacity, and retained engineering work. Vercel Fluid compute begins at $0.128 per active CPU-hour and $0.0106 per provisioned GB-hour in lower-cost US regions. Northflank can reduce total cost for sustained and mixed workloads, such as services, jobs, databases, and GPU applications, through per-second pricing, no pay-as-you-go seat fees, and BYOC that preserves cloud commitments while supporting custom plans, spot nodes, autoscaling, and workload scheduling. Vercel may cost less for bursty web workloads because active CPU is not billed during I/O waits, although memory charges continue during the invocation. ## When does Vercel fit your requirements? Vercel fits when frontend delivery and managed web infrastructure matter more than controlling a broad container runtime. - Your product is primarily a Next.js or framework-based web application. - You want automatic web previews and collaboration with minimal setup. - Functions, Cron Jobs, Workflows, and Marketplace data services cover your architecture. - You prefer automatic Fluid scaling to selecting container resources or managing cluster capacity. - Vercel's global delivery, microfrontends, analytics, and web observability are central requirements. ## When does Northflank fit your requirements? Northflank fits platform and enterprise teams, growing organizations, and individual engineers that need one platform for broader production workloads and deeper infrastructure control. - You run persistent services, workers, one-off or scheduled jobs, stateful services, or GPU workloads. - You need production BYOC across supported clouds, eligible existing Kubernetes, or qualified on-premises or bare-metal infrastructure. - Developers need Kubernetes abstraction while platform teams retain resource, scheduling, network, and policy controls. - Full-stack previews must create databases, jobs, volumes, private services, and multiple components together. - Cloud commitments, specialized compute, data residency, or sustained workloads make direct billing and utilization controls important. ## Northflank vs Vercel: final decision The decision depends on whether you are standardizing a broad production platform or optimizing a web delivery workflow. Vercel fits frontend-led web products that benefit from framework-aware builds, global delivery, collaborative previews, and Fluid compute. Northflank fits engineering, platform, and enterprise teams that need governed developer self-service, Kubernetes abstraction, and one control plane for full-stack applications, services, jobs, managed data, previews, optional GPUs, and infrastructure across Northflank Cloud, production multi-cloud BYOC, or BYOK. Test a representative frontend, API, background task, stateful dependency, preview, private connection, observability export, traffic pattern, and monthly cost. The better fit is the platform that handles the complete topology with the ownership boundary your team requires. ## Frequently asked questions about Northflank vs Vercel ### Is Northflank better than Vercel? Northflank better suits teams needing one platform for full-stack applications, services, jobs, databases, GPUs, previews, Kubernetes abstraction, and production multi-cloud BYOC. Vercel better suits frontend-led web applications needing framework-aware builds and global delivery. ### Is Vercel only for frontend applications? No. Vercel supports APIs, server-side code, Cron Jobs, durable Workflows, SaaS, AI applications, and microfrontends. Its core runtime is not a general persistent-container or Kubernetes Job model. ### Does Vercel support BYOC? Yes. Vercel AWS BYOC is in private beta. Northflank has supported production multi-cloud BYOC since 2019 and offers BYOK for eligible cloud, on-premises, and bare-metal Kubernetes. ### Which platform is better for preview environments? Northflank previews reproduce full stacks with services, databases, jobs, volumes, private networking, and seed workflows. Vercel previews are oriented toward web review, with automatic URLs, sharing, and collaboration. ### Which platform is better for Kubernetes and enterprise infrastructure teams? Northflank fits enterprises and platform teams that need governed developer self-service while retaining control over clusters, node pools, resource plans, networking, scheduling, and deployment targets across production BYOC and eligible BYOK. Vercel fits enterprises that want a vendor-managed web runtime without Kubernetes-level infrastructure control. ### Which is cheaper, Northflank or Vercel? Pricing depends on the workload and operating model. Northflank can reduce total cost for sustained services and stacks combining services, jobs, databases, and GPUs through per-second pricing, no pay-as-you-go seat fees, and BYOC. Vercel Fluid compute bills active CPU only while code executes, although memory charges continue during invocations. Compare total infrastructure, usage, seats, add-ons, and operational responsibility. ## Related articles about deployment platform selection - [Best Vercel alternatives](https://northflank.com/blog/best-vercel-alternatives-for-scalable-deployments) - [Best BYOC alternatives to Vercel](https://northflank.com/blog/best-byoc-alternatives-to-vercel) - [Northflank vs Railway](https://northflank.com/blog/northflank-vs-railway) - [Northflank vs Render](https://northflank.com/blog/northflank-vs-render)

How to build efficient monorepo preview environments

2026-08-26T16:15:00.000Z

## TL;DR: how to build efficient monorepo preview environments - **Detect what changed:** identify which services and shared packages were affected by the pull request. - **Build only what needs rebuilding:** use dependency relationships to determine which services require a new build. - **Reuse unchanged services:** avoid rebuilding services that were not affected, while keeping them available in the complete preview environment. - **Deploy the full environment:** use a preview blueprint to provision all the services, databases, and infrastructure required to test the application. - **Clean up automatically:** tear down preview environments when pull requests are merged or closed to control resource usage and costs. > [Northflank](https://northflank.com/) lets you create full-stack preview environments for monorepos without rebuilding every service on every pull request. Build only affected services, provision the complete environment with databases and supporting services, and automatically tear it down when the PR is closed. Run it on [Northflank's managed cloud](https://northflank.com/features/managed-cloud) or [in your own AWS, GCP, Azure, or on-premises infrastructure](https://northflank.com/features/bring-your-own-cloud). [Get started with Northflank](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > Preview environments are straightforward when a repository contains a single application. A pull request changes the application, you build it, deploy it, and the team gets a URL. The build takes as long as it takes and the whole thing deploys, or it does not. Monorepos make this harder. A repository with twelve services, four shared packages, and a handful of workers has a different problem: a PR that touches one service should not rebuild and redeploy eleven others. At three services this does not matter. At twelve it wastes ten minutes per PR. At thirty it makes preview environments unusable. The goal is a preview environment that is proportional to the change being tested. ## Why monorepo preview environments are harder than single-repo A single-repo preview environment has one question to answer: did the code change? Yes, so build and deploy it. A monorepo preview environment has two additional questions. First, which services changed? You need to detect the changed files in the PR and map them to services. Second, which services are affected by those changes? A change to a shared authentication package does not change the authentication package's directory alone. It changes every service that imports that package. Without a dependency graph, you either rebuild everything (slow, expensive, misses the point) or rebuild only the directly modified service (fast, but potentially leaves other services running against a version of the shared package they are no longer compatible with). Both questions require answers before you know what to build. Neither is present in single-repo preview environment implementations. ## The three-layer problem Before getting into implementation, it helps to separate three distinct problems that look like one problem. **Layer 1: What changed.** This is a git question. Which files are different between the PR branch and the merge base? This produces a list of file paths. **Layer 2: What needs to rebuild.** This is a dependency question. Given the changed files, which services need a new image built? Some services need a rebuild because their own source changed. Others need a rebuild because a shared package they depend on changed. This requires a dependency graph. **Layer 3: What needs to deploy.** This is a preview environment question. The full preview environment needs all services running, including services that did not change and do not need a rebuild. Those services reuse their existing images. This is distinct from layer 2: you may rebuild two services but deploy all twelve. Most implementations conflate these three layers and end up doing one of two things: rebuilding and redeploying everything (ignoring layers 1 and 2) or rebuilding only changed services and deploying an incomplete environment (handling layer 1 but not layer 3). Getting all three right is what makes monorepo preview environments both efficient and complete. ## How path filters solve the direct change case Deployment platforms like Northflank handle change detection through path filters: per-service configuration that defines which file paths should trigger a build for that service. When a PR opens, the platform checks which paths changed and triggers builds only for the services whose path filters match. A typical monorepo layout: ``` monorepo/ ├── apps/ │ ├── web/ │ └── api/ ├── services/ │ ├── payments/ │ └── notifications/ └── packages/ ├── auth/ └── database/ ``` Path filter configuration for the direct change case: ```yaml services: web: paths: - apps/web/** api: paths: - apps/api/** payments: paths: - services/payments/** notifications: paths: - services/notifications/** ``` A PR touching `services/payments/src/routes.ts` triggers a build for `payments` and nothing else. The platform handles the rest: detecting the changed paths, matching them against configured filters, triggering the right builds, and leaving everything else alone. ## The shared package problem and how to solve it with path filters Path filters for direct service changes are straightforward. The part that requires deliberate configuration is shared packages. Consider `packages/auth`, imported by `apps/api`, `apps/web`, and `services/payments`. A change to `packages/auth` does not change any file inside those three service directories. With only direct path filters configured, none of them would trigger a rebuild. You would deploy a preview environment where those three services are running against the new version of `packages/auth` without having been rebuilt against it. The fix is to include the shared package path in the path filters of every service that consumes it: ```yaml services: api: paths: - apps/api/** - packages/auth/** - packages/database/** web: paths: - apps/web/** - packages/auth/** payments: paths: - services/payments/** - packages/auth/** ``` Now a change to `packages/auth` triggers builds for `api`, `web`, and `payments` , every service that imports it without touching services that do not. **Transitive dependencies:** The cascade can go deeper. If `packages/database` is imported by `packages/auth`, and `packages/auth` is imported by `apps/api`, then a change to `packages/database` should trigger a rebuild of `apps/api`. You account for this by including all transitive dependency paths in each service's path filter: ```yaml services: api: paths: - apps/api/** - packages/auth/** # direct dependency - packages/database/** # dependency of auth ``` **Global invalidation paths:** Some changes should rebuild all services regardless of which service imports what. Lockfile changes (`package-lock.json`, `yarn.lock`, `requirements.txt`) mean the installed versions of dependencies have changed, which can affect any service. A shared base Dockerfile change affects all images that use it. These paths go into every service's filter: ```yaml services: api: paths: - apps/api/** - packages/auth/** - packages/database/** - package-lock.json # global invalidation - Dockerfile.base # global invalidation ``` A useful reference for what triggers what: | Change | Services to rebuild | | --- | --- | | `apps/web/**` | web only | | `packages/auth/**` | all services that import auth | | `package-lock.json` | all Node.js services | | `Dockerfile.base` | all services using that base image | | `docs/**`, `README.md` | none | ## The preview environment blueprint for monorepos A preview blueprint defines the complete set of services, databases, and configuration that compose a preview environment. In a monorepo, the blueprint covers all services, not just the ones that changed in a given PR. When a PR opens: 1. Change detection and dependency graph resolution produce the affected service set 2. Affected services get new builds triggered; unchanged services skip the build step 3. The preview blueprint deploys the full environment: new image tags for affected services, existing image tags (from previous builds) for unchanged services 4. The environment is available at a unique URL When a new commit is pushed to the same PR: 1. The process repeats from step 1 2. Only newly affected services rebuild 3. The existing preview environment updates in-place: affected services redeploy with new images, unchanged services continue running When the PR merges or closes, the entire environment tears down. The blueprint approach means the preview environment is always complete: every service that the application needs is running, even if most of them did not change in this PR. A change to the payments service does not produce a preview environment with only the payments service. It produces a complete environment with all services, where the payments service has been updated. **Database isolation:** The blueprint should provision isolated database instances for the preview environment, not connect to shared staging databases. Changes to the payments service may include schema migrations. Those migrations should run against an isolated fork of staging, not against the shared staging database that other open PRs are also using. **Service discovery within the preview environment:** Services in the preview environment need to reach each other using the preview environment's internal URLs, not production or staging URLs. The blueprint handles this by injecting service URLs as environment variables at preview creation time. A frontend service that calls the API needs the API URL for this specific preview environment, not a hardcoded staging URL. ## How Northflank handles monorepo preview environments Northflank lets you combine **per-service path filters, independent builds, and preview blueprints** to create complete preview environments without rebuilding every service in a monorepo for every pull request. **Build only affected services:** Each service can have its own path filters that define which changes should trigger a new build. These can include the service's own source directory, shared packages it depends on, and other files that should invalidate the build. When a pull request changes matching paths, Northflank can trigger a build for the affected service without triggering builds for unrelated services. **Build services independently:** Services in the monorepo are built independently rather than through one monolithic build. This means a change to the API does not automatically require the frontend, worker, or other unrelated services to rebuild. It also makes it easier to apply different build configurations, caching strategies, and deployment settings to each service. **Deploy the complete preview environment:** A preview blueprint defines the services, databases, networking, and other resources that make up the environment. When a pull request is opened, the blueprint creates the full environment while the build system determines which services need new builds. This separates **what the preview environment contains** from **what needs to be rebuilt**, so a small change does not require rebuilding the entire monorepo. **Fork databases for isolated previews:** [Database](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank) forking lets preview environments use isolated PostgreSQL, MySQL, and MongoDB instances. Database forks can be created from staging backups, giving each preview environment its own data layer for testing migrations and application changes without affecting shared environments. **Tear down previews automatically:** When a pull request is merged or closed, its preview environment can be removed automatically. Teardown schedules and TTLs can also help clean up long-running previews and prevent unused environments from continuing to consume resources. **Run previews in your own cloud:** [BYOC](https://northflank.com/product/bring-your-own-cloud) allows preview environments, including their services and databases, to run inside your own cloud infrastructure. This gives teams the same monorepo preview workflow while retaining control over the underlying infrastructure. For a practical walkthrough, see [How to auto-create preview environments on every PR](https://northflank.com/blog/how-to-auto-create-preview-environments-on-every-pr). [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ## Conclusion Monorepo preview environments work best when you separate what changed, what needs to be rebuilt, and what needs to be deployed. This lets you rebuild only affected services while keeping the complete preview environment available for testing. [Northflank](https://northflank.com/) provides the infrastructure for this workflow, with per-service builds, preview blueprints, managed database forking, automatic teardown, and BYOC for teams that want to run preview environments in their own cloud. ## FAQs: how to build efficient monorepo preview environments ### What is a monorepo preview environment? A monorepo preview environment is an isolated environment created from a pull request in a repository containing multiple services or applications. It allows developers to test changes against the complete application without rebuilding every service in the monorepo. ### How do you detect which services changed in a monorepo? Compare the pull request with the merge base of its target branch, then map changed file paths to the services they belong to. Dependency graphs can then be used to identify additional services affected by changes to shared packages. ### How do dependency graphs affect monorepo preview environments? Dependency graphs show which services consume a changed package or service. A change to a shared package can therefore trigger builds for multiple services, even when those services have no direct source changes. ### Should unchanged services be rebuilt in a preview environment? Usually not. Unchanged services can reuse existing images or build artifacts while the services affected by the pull request receive new builds. The preview environment can still deploy the complete set of services. ### How can you prevent duplicate builds in a monorepo? Resolve all changed paths and dependency relationships into a single deduplicated set of affected services before creating the build matrix. This ensures each affected service is built once, even when multiple changes independently identify it. ## Related articles - [How to auto-create preview environments on every PR](https://northflank.com/blog/how-to-auto-create-preview-environments-on-every-pr) - [Which database strategy should you use for preview environments?](https://northflank.com/blog/which-database-strategy-should-you-use-for-preview-environments) - [How to set up CI/CD for a vibe-coded app](https://northflank.com/blog/how-to-set-up-ci-cd-for-a-vibe-coded-app)

Build vs buy an internal developer platform: costs, trade-offs, and ROI

2026-08-26T16:15:00.000Z

## TL;DR: build vs buy an internal developer platform - **Build** when you have highly specialized requirements, substantial platform engineering capacity, and a clear reason to own the platform long-term. - **Buy** when you want to reduce implementation time, engineering overhead, and ongoing maintenance. - **Buy and extend** when you want the flexibility of custom developer workflows without building and operating the entire platform yourself. > [Northflank](https://northflank.com/) is an internal developer platform that combines [application deployment](https://northflank.com/product/deployments), [sandboxes](https://northflank.com/product/sandboxes), [GPU workloads](https://northflank.com/product/gpu-paas), CI/CD, [preview environments](https://northflank.com/product/preview-environments), [databases](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), [governance](https://northflank.com/enterprise), [AI-native workflows](https://github.com/northflank/skills), and infrastructure management in one platform. It can also be extended with your own golden paths, templates, and developer workflows. Run it in [Northflank's managed cloud](https://northflank.com/features/managed-cloud) or [your own cloud with BYOC](https://northflank.com/product/bring-your-own-cloud). [Get started with Northflank](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > Building an internal developer platform can look like a straightforward engineering project. Your team already has Kubernetes, Terraform, CI/CD, and a few internal scripts, so why not put a self-service interface on top and build the rest as you go? The problem is that an internal developer platform is not just a portal. It becomes a product that your platform team has to build, operate, secure, integrate, document, and maintain for every engineering team that depends on it. The real build vs buy decision is therefore not about whether your team can build an IDP. It is whether owning the platform is a better use of engineering resources than adopting one that already exists. ## What you are actually building when you build an IDP The decision to build an internal developer platform is often framed as "we will set up Backstage" or "we will build a developer portal." This underestimates the scope by a significant margin. A developer portal is the interface layer. The execution layer, where workloads actually run, is a different set of problems entirely. A production-grade internal developer platform that developers genuinely depend on requires all of the following: | Component | What it requires | | --- | --- | | **CI/CD pipelines** | Build services, run tests, promote artifacts through environments | | **Deployment infrastructure** | Run services reliably, handle rollbacks, scale with traffic | | **Preview environments** | Spin up per pull request with isolated databases and services | | **Secrets management** | Store credentials and inject them at build and runtime | | **Managed databases** | Database provisioning developers can use without filing tickets | | **RBAC and SSO** | Access controls at the platform layer integrated with the identity provider | | **Audit logging** | Every deployment, secret access, and config change logged with identity | | **Network isolation** | Control how services reach each other and what they can reach externally | | **BYOC or cloud integrations** | Run workloads inside specific cloud accounts or on-premises | | **Observability** | Build logs, deployment status, and infrastructure metrics for developers | Each item on this list is a subsystem that needs to be designed, built, integrated with the others, documented, and maintained. A team that decides to build its own IDP is deciding to build and operate all of this, continuously. The gap between "we have a Backstage instance" and "we have an internal developer platform developers actually depend on" can represent months of dedicated platform engineering work, and that is for teams that move quickly. ## The cost of building: a breakdown | Cost | What you are paying for | | --- | --- | | **Engineering headcount** | Platform engineers to build, operate, upgrade, and support the IDP | | **Implementation time** | Months of engineering work before the platform is mature enough for broad adoption | | **Maintenance** | Upgrades, integrations, security patches, incidents, and platform improvements | | **Infrastructure** | Compute, Kubernetes, databases, networking, storage, and other cloud resources | | **Opportunity cost** | Engineering capacity spent on platform infrastructure instead of product work | | **Cloud waste** | Idle resources, overprovisioned infrastructure, and preview environments that are not cleaned up | | **Internal support** | Time spent helping developers troubleshoot and adapt to the platform | The highest cost is not the initial setup. It is the engineering capacity required to keep the platform useful over time. Your team has to maintain integrations, apply security and infrastructure updates, troubleshoot failures, and support developers as adoption grows. The exact cost varies by organization, but the pattern is consistent: building an IDP creates an ongoing platform engineering function, not a one-time project. **What research suggests** A production IDP can require several dedicated platform engineers, potentially representing high six figures or more in annual engineering compensation. Meaningful implementations commonly take months, with 6–12 months frequently cited for substantial self-hosted platform initiatives. ## Build vs buy: a direct comparison | | **Build** | **Buy** | | --- | --- | --- | | **Initial investment** | Engineering time and infrastructure | Platform subscription and setup | | **Time to value** | Months | Days to weeks | | **Flexibility** | Full control | Limited to the platform's capabilities and extension points | | **Maintenance** | Your team owns upgrades, integrations, and incidents | Vendor maintains the platform; your team manages configuration and integrations | | **Customization** | Build exactly what you need | Extend the platform where supported | | **Vendor dependency** | Infrastructure/tooling vendors | You depend on the vendor's roadmap and pricing | | **Engineering focus** | Build and operate the platform | Build the workflows and tooling that run on the platform | **The middle ground: buy and extend.** You do not have to choose between a completely custom platform and an off-the-shelf experience. You can buy the underlying platform and build your own golden paths, templates, policies, and developer workflows on top of it. This gives your platform team control over the developer experience without requiring them to build and maintain every piece of infrastructure underneath it. ## The decision framework Three factors determine which path is right: **Engineering headcount:** Below approximately 50 engineers, the cost of a dedicated platform team is hard to justify. Most of the problems an IDP solves are not yet severe enough to warrant the investment. Above approximately 200 engineers, the leverage from a platform is clear, and the cost of not having one is measurable in developer productivity and platform team ticket volume. Between 50 and 200, the answer depends on the other two factors. **Infrastructure scope:** If your requirements are standard (Git-triggered deployments, managed databases, preview environments, RBAC, SSO, BYOC into one or two cloud providers), existing platforms cover them. If your requirements are genuinely non-standard (specific networking topologies that no vendor supports, proprietary hardware integrations, classified infrastructure requirements), building may be the only path. **Maintenance capacity:** The question is not whether you can build an IDP. It is whether you can operate one indefinitely. Building is a project. Maintaining is a function. Before committing to the build path, budget for the team that will own the platform in years two, three, and five. | Situation | Recommendation | | --- | --- | | Under 50 engineers, standard requirements | Buy | | 50-200 engineers, standard requirements | Buy and extend | | 50-200 engineers, specialized requirements | Buy and extend or build specific components | | Over 200 engineers, standard requirements | Buy and extend | | Over 200 engineers, highly specialized requirements | Build, with a dedicated team | | Regulated industry requiring specific compliance architecture | Evaluate BYOC options before building | ## How Northflank fits the buy decision [Northflank](https://northflank.com/) is the deployment platform and execution layer for teams that want the capabilities of an internal developer platform without building and operating the underlying infrastructure. Where most IDP tools are portal layers (Backstage, Port) that provide a developer-facing interface but assume the execution layer exists underneath them, Northflank is the execution layer: the platform that actually runs workloads, provisions databases, manages secrets, enforces access controls, and provides the operational infrastructure that the portal sits on top of. What Northflank provides as a managed platform: - [**CI/CD pipelines**](https://northflank.com/product/deployments) from Git with framework detection, build logs, and deployment promotion - [**Preview environments per PR**](https://northflank.com/product/preview-environments) with isolated database instances and automatic teardown on merge - [**Managed databases**](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank) (PostgreSQL, MySQL, MongoDB, Redis, MinIO, RabbitMQ) with automated backups and restore capabilities - [**Secrets management**](https://northflank.com/docs/v1/application/secure/manage-secret-groups) via secret groups that inject credentials at build and runtime - [**RBAC**](https://northflank.com/docs/v1/application/secure/use-role-based-access-control) and [**SAML/OIDC SSO**](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication) with Okta, Entra ID, and Google Workspace - [**Audit logging**](https://northflank.com/docs/v1/application/observe/audit-logs) exported to SIEM, SOC 2 Type 2 certified - [**GPU workloads**](https://northflank.com/product/gpu-paas) (H100, H200, A100, L4, L40S, B200) alongside standard services - [**MicroVM sandbox isolation**](https://northflank.com/product/sandboxes) for AI agent workloads - [**AI-assisted development**](https://github.com/northflank/skills):Northflank Skills lets AI coding assistants provision infrastructure, create previews, deploy applications, and manage workloads within your platform's governance controls. - [**Self-serve BYOC**](https://northflank.com/product/bring-your-own-cloud) into AWS, GCP, Azure, Oracle, CoreWeave, Civo, on-premises, and bare-metal - [**Forward-deployed control plane**](https://northflank.com/enterprise) for regulated industries and air-gapped environments For teams on the buy and extend path, Northflank handles the execution layer. The platform team builds golden paths, service templates, and developer workflows on top of the platform rather than building and maintaining the platform itself. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ## Conclusion Building an internal developer platform can make sense when your infrastructure is highly specialized and owning the platform is strategically valuable. But for most teams, the bigger question is whether building and maintaining the underlying infrastructure is worth the engineering time, ongoing maintenance, and operational overhead. Northflank gives teams the benefits of buying without giving up control. You get a complete platform for application deployment, CI/CD, environments, databases, security, and infrastructure management, while BYOC lets you run it in your own cloud infrastructure. Your platform team can focus on creating the golden paths and developer workflows that are specific to your organization instead of spending years building and maintaining the platform underneath them. ## FAQ: build vs buy an internal developer platform ### Is it cheaper to build or buy an internal developer platform? It depends on the size of your engineering team, platform scope, and how much ongoing maintenance you can absorb. Building avoids a vendor subscription but introduces engineering, infrastructure, security, and maintenance costs. Buying adds a recurring platform cost but can reduce engineering headcount and time to value. ### How much does it cost to build an internal developer platform? There is no universal cost because IDP scope varies significantly. A meaningful self-hosted platform can require multiple dedicated engineers and several months of implementation. Current industry estimates commonly put self-hosted Backstage implementations in the 6 to 12 month range, with ongoing staffing requirements varying by organization and scope. ### When should you build an internal developer platform? Build when your platform has highly specific requirements that existing products cannot satisfy, or when the platform itself is strategically important enough to justify a dedicated engineering organization. You should also have the capacity to maintain it over the long term. ### When should you buy an internal developer platform? Buy when your organization needs common platform capabilities such as application deployment, CI/CD, environments, databases, security controls, and self-service workflows without wanting to build and maintain each capability internally. Buying is particularly attractive when reducing time to value and platform engineering overhead are priorities. ### Can you build on top of a bought internal developer platform? Yes. A bought platform can provide the underlying execution layer while your platform team builds organization-specific golden paths, templates, policies, and workflows on top. This "buy and extend" model lets teams customize the developer experience without owning the entire infrastructure platform. ## Related articles - [How to build an internal developer platform](https://northflank.com/blog/how-to-build-an-internal-developer-platform) - [Top internal developer portals in 2026](https://northflank.com/blog/top-internal-developer-portals) - [What is an AI internal developer platform (IDP)?](https://northflank.com/blog/what-is-an-ai-internal-developer-platform-idp)

Northflank vs Railway: which deployment platform should you choose?

2026-08-25T16:51:00.000Z

Northflank and Railway both provide direct application deployment workflows, but they support different infrastructure requirements. Railway runs application resources on Railway-managed infrastructure, while Northflank combines developer self-service with Kubernetes abstraction, enterprise governance, and deployment on Northflank Cloud or your own infrastructure. The choice depends on your applications, infrastructure, and required control. This evidence-based comparison covers workloads, developer experience, previews, networking, scaling, security, Bring Your Own Cloud (BYOC), and pricing. ## TL;DR: Northflank vs Railway - **Railway fits teams deploying web applications, APIs, workers, cron jobs, Functions, and database templates** on Railway-managed infrastructure without BYOC or cluster-level control. - **Northflank fits enterprise and platform teams that need governed developer self-service.** One control plane covers services, jobs, managed data, previews, optional GPUs, Northflank Cloud, production BYOC, and eligible on-premises or bare-metal Kubernetes. Startups and individual engineers can use the same platform and Git-to-deploy workflow. - **Pricing follows different models.** Railway combines a plan minimum with resource consumption. Northflank offers usage-based, pay-as-you-go pricing billed per second on Northflank Cloud; BYOC lets teams pay their cloud provider directly and retain existing credits, commitments, and negotiated rates. For infrastructure placement or broader workloads, [Northflank](https://northflank.com/) provides governed developer self-service and Kubernetes abstraction across [Northflank Cloud](https://northflank.com/features/managed-cloud), [production BYOC and Bring Your Own Kubernetes (BYOK)](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements), and [GPU-backed workloads](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud). Platform teams control clusters, networks, resources, and policies without making developers operate Kubernetes. Northflank has [supported production BYOC since 2019](https://northflank.com/blog/is-byoc-the-future-of-software-deployment). [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## Northflank vs Railway comparison table This table compares the requirements most likely to affect your decision. Product and plan information is current as of 25 August 2026. | Requirement | Northflank | Railway | | --- | --- | --- | | Best for | Enterprise and platform teams needing governed self-service across managed cloud, production BYOC, eligible Kubernetes, and optional GPUs | Applications that fit Railway's project model and Railway-managed infrastructure | | Workload and resource examples | Services; workers; one-off, API-triggered, and cron jobs; builds; managed databases, caches, queues, object storage; volumes; CPU and GPU workloads | Persistent services; workers; cron jobs; TypeScript Functions; database templates; volumes; and buckets | | Deployment workflow | Git repositories, Dockerfiles, Buildpacks, external container images, combined or separate CI/CD, workflows, templates, GitOps, API, and CLI. | GitHub, local directory, images, Railpack, Dockerfile, CLI, and Railway IaC | | Infrastructure model | Northflank Cloud; production BYOC across AWS, GCP, Azure, and other providers; or eligible cloud, on-premises, and bare-metal Kubernetes through BYOK | Railway-managed infrastructure or dedicated Railway-managed VMs | | BYOC and BYOK | Production BYOC in AWS, GCP, Azure, and other providers; BYOK for eligible cloud, on-premises, and bare-metal Kubernetes | Not offered; dedicated VMs remain Railway-managed | | Data services | Managed addons with backup, upgrade, scaling, replica, and HA workflows | Unmanaged database templates with native volume backups, Postgres PITR, and HA templates | | GPU workloads | Managed-cloud GPUs and GPU node pools in BYOC | Not currently offered | | Preview environments | Full-stack blueprints containing services, jobs, databases, volumes, networking, and URLs | PR environments copied from a base environment | | Private networking | Services, jobs, and addons, plus customer-network options in BYOC | Encrypted private network scoped to one project environment | | Autoscaling | CPU, memory, RPS, or custom Prometheus metrics; BYOC node-pool controls | Dynamic CPU and memory use to plan limits; user-configured replicas | | Observability | Logs and metrics across builds and workloads, alerts, health checks, and native log sinks | Build/runtime logs, Log Explorer, resource metrics, and third-party telemetry | | Security and enterprise | SOC 2 Type 2 and HIPAA compliant; granular access, audit events, workload identities, network controls, forward-deployed options, and SLAs | SOC 2 Type II and SOC 3 certified; SSO, RBAC, audit logs, HIPAA BAA, support, and dedicated instances based on plan or spend | | Pricing model | Per-second Northflank Cloud usage; BYOC platform fees plus direct cloud-provider billing | Plan minimum plus minute-metered resource consumption | ## Who are Northflank and Railway designed for? Railway uses a project model for resources running on its infrastructure. Northflank is enterprise-first while keeping application delivery self-service, making the same platform accessible to startups and solo engineers. ### Railway Railway groups services, databases, variables, volumes, and environments on a project canvas. Teams deploy from GitHub, a local directory, or an image using Railpack, Dockerfiles, or `railway up`. ### Northflank Northflank's Kubernetes abstraction lets platform, SRE, security, and infrastructure teams provide governed delivery for applications, data, environments, and releases while retaining control over clusters, networks, policies, resources, and observability. Developers avoid operating Kubernetes directly. Teams can start with a [combined Git-to-deploy service](https://northflank.com/docs/v1/application/getting-started/build-and-deploy-your-code) and add separate builds and [workflows](https://northflank.com/docs/v1/application/release/configure-workflows) for release controls when needed. Enterprises gain governance and infrastructure flexibility; startups and individual engineers use the same developer experience without requiring a platform team. ## What is the developer experience like on Northflank and Railway? Both provide direct Git-to-deploy workflows. Railway centers operations on its project resources; Northflank exposes optional build, release, environment, and infrastructure controls. Railway users connect a repository or run `railway up`, then build with Railpack or Dockerfile. Project Infrastructure as Code uses `.railway/railway.ts`; legacy `railway.toml` and `railway.json` are deprecated and retire on 1 December 2026. Northflank combined services support repository deployments. [Workflows](https://northflank.com/docs/v1/application/getting-started/set-up-environments) coordinate services, migrations, addons, and image promotion. [Templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code), [GitOps](https://northflank.com/docs/v1/application/infrastructure-as-code/gitops-on-northflank), the [API](https://northflank.com/docs/v1/api/use-the-api), and [CLI](https://northflank.com/docs/v1/api/use-the-cli) support automation. Railway provides build, deploy, environment, and project workflows. Northflank adds graph-based orchestration across services, jobs, addons, and infrastructure targets. Railway provides Railway Agent, CLI and MCP integrations, and a `use-railway` skill. Northflank provides [Northflank Skills](https://github.com/northflank/skills) for Codex, Claude Code, Cursor, OpenCode, Windsurf, and other coding agents, with actions governed by API or CLI credentials, RBAC, and audit controls. ## What applications and workloads can you run on Northflank and Railway? Both cover web stacks; Northflank adds broader job, managed stateful-service, and GPU support. ### Services and jobs on Northflank and Railway Railway persistent services run web applications, APIs, workers, and other continuous containers. Cron jobs run scheduled tasks, while Functions run single-file TypeScript code. Northflank services run applications and workers. Jobs support manual runs and cron schedules with retry, time-limit, and concurrency policies for migrations, batch processing, maintenance, and ML tasks. ### Databases and state on Northflank and Railway Railway documents its database templates as unmanaged. It provides volume backups, Postgres point-in-time recovery, and HA templates, while customers remain responsible for tuning, monitoring, security, and disaster-recovery design. Northflank provides [managed addons](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank) with backup, upgrade, scaling, replica, and HA workflows for databases, caches, queues, and object storage. Custom stateful software can still use persistent volumes. ### GPU workloads on Northflank and Railway Railway does not currently offer GPU instances. Northflank supports [GPU workloads](https://northflank.com/cloud/gpus) for inference, training, notebooks, and accelerated containers through managed plans and GPU node pools in supported customer cloud accounts. This keeps APIs, workers, data services, and GPUs on one platform. ## How do previews and private networking work on Northflank and Railway? Railway copies a base environment for each pull request. Northflank can compose full-stack previews and extend private connectivity into customer networks through BYOC. Railway PR environments replicate a base environment’s services, variables, and networking, then delete the environment when the pull request closes or merges. Northflank [Preview Blueprints](https://northflank.com/product/preview-environments) create services, jobs, databases, volumes, private connections, and URLs from Git, webhook, or API triggers. Conditional nodes can vary topology or prepare preview data. Railway provides internal DNS through an encrypted WireGuard network scoped to each project environment. Northflank [private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank) connects services, jobs, and addons; BYOC places runtimes inside customer networks when required. ## What infrastructure choices do Northflank and Railway provide? Railway operates its application infrastructure. Northflank offers managed infrastructure, provisioned BYOC clusters, and eligible existing Kubernetes. Railway deploys workloads to Railway Metal in California, Virginia, Amsterdam, or Singapore. Enterprise customers can use dedicated Railway-managed VMs. The infrastructure remains under Railway’s management. Northflank has supported production [BYOC](https://northflank.com/features/bring-your-own-cloud) since 2019. It provisions and manages Kubernetes clusters in supported AWS, Google Cloud, Azure, Oracle Cloud, Civo, CoreWeave, and Nebius accounts. BYOK covers eligible Kubernetes, including on-premises and bare metal, subject to Northflank’s cluster requirements. The customer owns its account, provider bill, and capacity choices. Northflank manages provisioned-cluster upgrades, scaling, and maintenance while developers use application abstractions. BYOK leaves more cluster responsibility with the customer. In BYOC, runtime and workload data remain in the customer’s cloud account while Northflank hosts control-plane metadata; other data locations depend on configuration. In Northflank’s [Lifted/Upwork case study](https://northflank.com/blog/upwork-lifted-runs-production-workloads-inside-their-own-vpc-with-northflank), Lifted runs deployments, previews, autoscaling, and secrets inside its AWS VPC. The case study reports that one engineer later moved 13 development and production services from GCP to AWS in four hours. This distinction matters when buyers require cloud ownership, residency, commitments, private connectivity, Kubernetes control, or specialist infrastructure. ## How do scaling and resource controls work on Northflank and Railway? Railway uses dynamic resource consumption with user-configured replicas. Northflank adds automatic horizontal scaling from application metrics and cluster-level capacity controls in BYOC. Railway services consume CPU and memory dynamically up to plan limits. Teams set replica counts across regions. Replicated services cannot attach volumes, so state must use a database, bucket, or shared system. Northflank supports resource selection, instance counts, and [horizontal autoscaling](https://northflank.com/docs/v1/application/scale/autoscale-deployments) based on CPU, memory, requests per second, or custom Prometheus metrics. Managed addons can scale compute, storage, and replicas. BYOC also exposes node pools, cluster autoscaling, spot capacity, zone placement, affinities, GPUs, and custom requests and limits for production, availability, placement, and cost requirements. ## What observability and security controls do Northflank and Railway provide? Both include deployment visibility and offer identity and governance controls, but their operational depth differs. Security, compliance, and plan information is current as of 25 August 2026. Railway provides build and runtime logs, Log Explorer, and CPU, memory, disk, and network metrics. Application latency, errors, traces, and business metrics require third-party instrumentation. Log forwarding uses a service or application telemetry rather than a native log-drain setting. Northflank provides logs and metrics for builds, services, jobs, and addons, plus health checks and infrastructure and spend alerts. [Log sinks](https://northflank.com/docs/v1/application/observe/configure-log-sinks) forward project or account data to observability tools, S3, or HTTP endpoints. Railway provides SSO, RBAC, extended audit logs, support, and dedicated instances through Enterprise or Pro committed-spend tiers. [Northflank Enterprise](https://northflank.com/docs/v1/application/enterprise) adds SSO/SAML, SCIM/JIT, scoped access, audit and infrastructure events, workload identities, template review, network controls, and forward-deployed options. ### Compliance on Northflank and Railway Railway is SOC 2 Type II and SOC 3 certified; a HIPAA BAA is available through its $1,000 monthly committed-spend tier on Pro. [Northflank is SOC 2 Type 2 and HIPAA compliant](https://northflank.com/security), with BAAs supported under Enterprise contracts. Buyers should confirm contract terms and shared responsibilities. Railway’s governance applies to its managed platform. Northflank BYOC extends governance into customer infrastructure, supporting placement, residency, and infrastructure-visibility requirements. ## How do Northflank and Railway compare on pricing and total cost of ownership? Both use usage-based pricing, but their billing units and operational responsibilities differ. Prices were checked on 25 August 2026. - **Railway:** Free is $0 with $1 of monthly resources, Hobby is $5, Pro is $20, and Enterprise is custom. The monthly plan amount counts toward usage. Standard rates are $10 per GB of RAM per month, $20 per vCPU per month, $0.15 per GB per month for volume storage, and $0.05 per GB for egress. Compute is metered by the minute. - **Northflank:** The free Sandbox includes always-on compute, two services, one database, and two cron jobs. [Pay-as-you-go](https://northflank.com/pricing) is self-service, has no seat fees, and uses per-second billing. Northflank Cloud rates are $0.01667 per vCPU hour and $0.00833 per GB hour. Enterprise adds invoice-based billing, volume discounts, commitments, SSO, audit logs, HA/DR, on-premises deployment, 24/7 support, SLAs, and FDE onboarding. BYOC infrastructure is billed directly by the cloud provider, while Northflank charges disclosed platform rates of $0.01389 per vCPU hour, $0.00139 per GB hour, and $0.00278 per GB of GPU VRAM hour. - **Total cost of ownership:** Both platforms reduce operational work through different models. Railway operates the infrastructure. Northflank abstracts Kubernetes while preserving infrastructure control. Northflank BYOC lets teams use cloud credits, commitments, spot capacity, node-pool autoscaling, workload scheduling, and custom resource plans. Compare infrastructure, data operations, traffic, support, and the engineering work each platform removes or leaves with your team. ## When does Railway fit your requirements? Choose Railway when your application fits its project model and Railway-managed infrastructure. Railway fits when: - You are deploying a web app, API, worker, cron task, or compact multi-service stack. - Your team uses its project canvas, templates, GitHub workflow, or `railway up` loop. - Railway-managed regions meet your security, residency, and procurement requirements. - Manual replica configuration and external application telemetry are acceptable for your production model. - You accept Railway’s unmanaged database model: native backups, Postgres PITR, and HA templates are available, while your team owns tuning, monitoring, security, and disaster-recovery design. Railway also provides multi-region replicas, HA Postgres, PITR, Enterprise controls, and SLAs for production applications that do not require customer-cloud or Kubernetes control. ## When does Northflank fit your requirements? Northflank fits enterprise platform teams and growing organizations that need governed self-service with workload, governance, and infrastructure control. Northflank fits when: - You need managed data services, backups, upgrades, and HA alongside applications. - You need jobs, migrations, image promotion, or coordinated multi-resource releases. - Services need metric-driven horizontal autoscaling rather than only user-configured replica counts. - Your stack includes GPU inference, training, notebooks, or other accelerated containers. - Workloads must run in your cloud account, VPC, selected provider regions, or eligible on-premises and bare-metal Kubernetes infrastructure. - Platform teams need resource plans, node pools, placement, log sinks, workload identities, or enterprise governance. - Developers need a PaaS workflow while infrastructure teams control Kubernetes, networking, placement, and cloud costs. ## Northflank vs Railway: final decision Railway fits applications that remain within its project and vendor-operated infrastructure model. Northflank fits engineering and platform teams, from startups to enterprises, that want direct developer workflows plus one control plane for broader workloads across managed or customer-controlled infrastructure. Test a representative service, job, datastore, preview, private dependency, observability export, expected scale, and monthly cost before committing. ## Frequently asked questions about Northflank vs Railway ### Is Northflank better than Railway? Northflank fits managed addons, autoscaling, GPUs, BYOC/BYOK, and infrastructure-control requirements. Railway fits applications whose requirements are met by its provider-managed model. ### Is Railway easier to use than Northflank? Railway keeps resources within its managed-infrastructure model. Northflank combined services provide a similar starting path, with workflows, addons, and infrastructure controls as requirements grow. ### Does Railway support BYOC? No. As of 25 August 2026, Railway’s hosting model is Railway-managed, including dedicated VMs. Northflank supports production BYOC plus BYOK for eligible cloud, on-premises, and bare-metal Kubernetes. ### Which platform is better for enterprise teams? Railway suits enterprises whose requirements fit its managed infrastructure model. Northflank is designed for enterprises needing Kubernetes abstraction, governed developer self-service, BYOC or private infrastructure, granular controls, and forward-deployed options. ### Which is cheaper, Northflank or Railway? Pricing depends on the workload and deployment model. Railway combines a monthly plan minimum with minute-metered consumption. Northflank offers per-second cloud billing, no seat fees, and BYOC that can use existing cloud commitments, credits, negotiated rates, and infrastructure controls. ## Related articles about deployment platform selection - [6 best Railway alternatives](https://northflank.com/blog/railway-alternatives) - [Does Railway have BYOC?](https://northflank.com/blog/does-railway-have-byoc) - [Should you use Railway for enterprise deployments?](https://northflank.com/blog/should-you-use-railway-for-enterprise-deployments) - [What is a deployment automation platform?](https://northflank.com/blog/deployment-automation-platform) - [How do preview environments scale?](https://northflank.com/blog/scale-preview-environments-ai-generated-code)

Northflank vs Render: which deployment platform should you choose?

2026-08-25T16:50:00.000Z

Render fits conventional web stacks on vendor-managed infrastructure; Northflank combines developer self-service with production-grade infrastructure and governance controls. The decision depends on workload, location, and control. The comparison covers workloads, developer experience, infrastructure, networking, operations, security, compliance, pricing, and responsibility. ## TL;DR: Northflank vs Render Render presents fewer infrastructure choices for common web applications, while Northflank supports more applications, workloads, and deployment models. - **Render fits teams deploying conventional web stacks** built from static sites, web and private services, background workers, cron jobs, Render Postgres, and Render Key Value on Render-operated infrastructure, without a requirement for BYOC or cluster-level control. - **Northflank fits platform and engineering teams that need governed developer self-service**, combining Git-to-deploy workflows and Kubernetes abstraction with one control plane for services, jobs, data, optional GPUs, Northflank Cloud, production BYOC, and eligible on-premises or bare-metal Kubernetes. - **Pricing follows different models:** Render combines a workspace subscription with resource charges; Northflank Cloud uses granular usage pricing; Northflank BYOC combines platform fees with your cloud-provider bill. Total cost also includes storage, traffic, previews, and retained engineering work. For infrastructure placement or broader workloads, [Northflank](https://northflank.com/) provides developer self-service and Kubernetes abstraction across Northflank Cloud, [production BYOC and BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements), and [GPU-backed workloads](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud). Platform teams retain control over clusters, networks, resources, and policies without making developers operate Kubernetes. Northflank has [supported production BYOC since 2019](https://northflank.com/blog/is-byoc-the-future-of-software-deployment). [Get started with Northflank](https://app.northflank.com/signup), or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your requirements. ## Northflank vs Render comparison table This table compares the requirements most likely to affect your decision. Product and plan information is current as of 25 August 2026. | Requirement | Northflank | Render | | --- | --- | --- | | Best for | Enterprise and platform teams that need governed developer self-service and one control plane across Northflank Cloud, production BYOC, eligible on-premises or bare-metal Kubernetes, and optional GPU capacity | Deploying conventional web stacks through static sites, web and private services, workers, cron jobs, Render Postgres, and Render Key Value on Render-operated infrastructure | | Workload and resource examples | Web and private services; workers; one-off, API-triggered, and scheduled or cron jobs; builds; managed databases, caches, queues, and custom addons; persistent volumes; and sandboxed CPU or GPU workloads | Static sites; web and private services; workers; cron and one-off jobs; Workflows; Postgres; Key Value; and persistent disks | | Deployment workflow | Git, Dockerfile, buildpacks, external images, combined or separate CI/CD, workflows, release pipelines, templates, GitOps, API, and CLI | Git, native runtimes, Dockerfile, external images, Blueprints, Terraform, API, and CLI | | Infrastructure model | Kubernetes-based platform across Northflank-managed or customer-controlled infrastructure | Containerized instances on Render-operated infrastructure | | BYOC and private infrastructure | Production BYOC across AWS, GCP, Azure, and other providers; BYOK for eligible public-cloud, on-premises, and bare-metal Kubernetes | Not supported; workloads run on Render-operated infrastructure | | Data services | PostgreSQL, MySQL, MongoDB, Redis, RabbitMQ, and other managed addons | Render Postgres and Render Key Value | | GPU workloads | Managed-cloud GPU plans and GPU node pools in BYOC for services and jobs | Not currently supported | | Preview environments | Full-stack preview blueprints for pull requests, branches, or manual runs, including services, databases, jobs, and volumes | Blueprint-defined preview instances of services and datastores on Pro or higher | | Private networking | Private ports, multi-project networking, Tailscale, and port or path policies | Same-region private network, private services, and plan-dependent environment isolation or AWS Private Link connections | | Autoscaling | CPU, memory, requests per second, or custom Prometheus metrics; BYOC node-pool autoscaling and scheduling controls | CPU and memory autoscaling on Pro or higher | | Observability | Logs and metrics for builds, services, jobs, and addons, plus log sinks and API access | Dashboard logs and metrics, plus OTel metric streams on Pro or higher | | Security and enterprise | SOC 2 Type 2 and HIPAA compliance; granular RBAC, SAML or OIDC SSO, directory sync, scoped API access, multi-level audit logs, engineering support, and forward-deployed or air-gapped options | SOC 2 Type 2 and ISO 27001 compliance; audit logs on Pro; SAML SSO, SCIM, additional roles, organizations, and HIPAA-enabled workspaces on Scale | | Pricing model | Per-second Northflank Cloud usage; BYOC platform fees plus infrastructure billed directly by the cloud provider | Workspace subscription plus compute, data, storage, traffic, and optional charges | ## Who are Northflank and Render designed for? Render uses a small set of managed service types for common web infrastructure. Northflank is designed for production and enterprise deployment while keeping conventional application delivery self-service. ### Render Render covers static frontends, web APIs, private services, workers, scheduled tasks, PostgreSQL, and a Redis-compatible store on Render-operated infrastructure. Workflows adds distributed TypeScript and Python tasks in beta. ### Northflank Northflank's Kubernetes abstraction lets enterprise platform teams provide self-service delivery for services, jobs, databases, environments, and releases while retaining control of clusters, networks, policies, resources, and observability. Northflank's [Upwork Lifted case study](https://northflank.com/blog/upwork-lifted-runs-production-workloads-inside-their-own-vpc-with-northflank) shows developers deploy without infrastructure tickets while SRE and security retain AWS VPC visibility. Northflank serves enterprises needing governance, customer-controlled infrastructure, and cross-team self-service; startups and individual engineers can use the same platform. ## What are the main differences between Northflank and Render? Northflank and Render differ in workload breadth, workflow, infrastructure ownership, networking, scaling, and operational depth. Feature and plan details below are current as of 25 August 2026. ### Application and workload support on Northflank and Render Both cover web backends, workers, scheduled execution, containers, storage, and managed data. Northflank supports more workload and datastore types; Render defines static-site and web-service types alongside Postgres and Key Value. Render's web and private services handle traffic, workers initiate outbound requests, and cron jobs run scheduled commands. Workflows orchestrates independent, chained, or parallel TypeScript and Python tasks in beta. Northflank separates long-running services from one-off, scheduled, or API-triggered jobs. [Managed addons](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank) span databases, caches, and queues beyond Render's native set. For GPUs, Northflank lists [managed-cloud NVIDIA plans](https://northflank.com/pricing) and schedules services or jobs on [BYOC GPU node pools](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud). ### Developer experience on Northflank and Render Both provide direct Git-to-deploy workflows. Render centers deployment on its service types; Northflank exposes optional build, release, infrastructure, and environment controls. On Render, connect a repository or image, select a service type and instance, and deploy. Automation options include `render.yaml`, CLI, REST API, Terraform, and an official MCP server for compatible clients. On Northflank, a combined service joins CI and deployment; teams can separate them later and use [workflows and preview blueprints](https://northflank.com/docs/v1/application/getting-started/set-up-environments) for migrations, environments, and promotions. [Templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code), [GitOps](https://northflank.com/docs/v1/application/infrastructure-as-code/gitops-on-northflank), the [API](https://northflank.com/docs/v1/api/use-the-api), [CLI](https://northflank.com/docs/v1/api/use-the-cli), and [JavaScript client](https://northflank.com/docs/v1/api/use-the-javascript-client) support automation. Teams can extend these interfaces into AI-assisted workflows with [Northflank Skills](https://github.com/northflank/skills) for Claude Code, Codex, and Cursor; actions remain governed by API or CLI credentials, RBAC, and audit controls. Render exposes fewer platform concepts. Northflank lets teams start with Git-to-deploy and adopt repeatable releases, mixed workloads, cross-cluster workflows, and deeper controls as needed. ### Infrastructure and deployment models on Northflank and Render Render runs the evaluated services as containerized instances on Render infrastructure. Northflank lets teams choose Northflank Cloud, a newly provisioned Kubernetes cluster in their cloud account through Bring Your Own Cloud (BYOC), or an eligible existing Kubernetes cluster through Bring Your Own Kubernetes (BYOK). Render operates the infrastructure; customers configure applications within its regions, instance types, network model, and limits. Northflank supplies compute on [Northflank Cloud](https://northflank.com/features/managed-cloud). With its production [BYOC](https://northflank.com/docs/v1/application/bring-your-own-cloud/use-other-cloud-providers-with-northflank), available since 2019, your organization owns the cloud account and bill while Northflank provisions and manages Kubernetes. Integrations include AWS, Google Cloud, Azure, Civo, Oracle Cloud, CoreWeave, and Nebius. For existing infrastructure, [BYOK](https://northflank.com/features/platform) imports an eligible CNCF-certified cluster from a cloud provider, on-premises data center, or bare-metal installation. In BYOC, runtime and workload data sit in your cloud account while Northflank hosts control-plane metadata; other data locations vary by configuration. The [BYOC and BYOK requirements](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements) specify at least 12 vCPU and 24 GB per cluster; BYOC permits one node, while BYOK requires three. Customers retain responsibility for their account, policies, charges, and applications. ### Preview environments and private networking on Northflank and Render Render preview environments create Blueprint services and datastores on Pro or higher. They do not copy production data, incur normal charges, use pull-request or inactivity cleanup rules, and disable autoscaling. Northflank [preview blueprints](https://northflank.com/docs/v1/application/release/manage-preview-blueprints) create services, databases, jobs, and volumes for pull requests, branches, or manual runs, with unique URLs and cleanup rules. Render services in the same region and workspace share a private network. Pro and higher add environment isolation and Private Link connections to compatible AWS-hosted services. Scale and Enterprise add inbound IP rules for web services, static sites, environments, and workspaces; datastore-level rules are available on every plan. Northflank exposes [private ports](https://northflank.com/docs/v1/application/network/networking-on-northflank) across services, jobs, databases, and addons, with multi-project networking, Tailscale, IP policies, and path-level rules. ### Scaling, resource controls and observability on Northflank and Render Render scales eligible services to 100 instances; Pro and higher add CPU- or memory-based autoscaling. Each instance is billed separately, and services with persistent disks cannot scale horizontally. Northflank [autoscaling](https://northflank.com/docs/v1/application/scale/autoscale-deployments) uses CPU, memory, requests per second, or custom Prometheus metrics. BYOC adds node-pool autoscaling, spot capacity, workload affinity, build placement, and custom resource plans to align capacity with demand. Render includes runtime logs and applicable resource and HTTP metrics. Pro adds request logs, latency metrics, and OpenTelemetry metric streaming, with workload exclusions. Northflank provides UI and API logs and metrics for builds, deployments, jobs, and addons. [Log sinks](https://northflank.com/docs/v1/application/observe/configure-log-sinks) route to supported providers, Amazon S3, or HTTP. Application traces and business telemetry require application instrumentation. ## Which security and enterprise controls do Northflank and Render provide? Security, compliance, and plan details are current as of 25 August 2026. Render is SOC 2 Type 2 and ISO 27001 compliant. Pro includes compliance reports and audit logs; Scale adds organizations, SAML SSO, SCIM, additional roles, organization audit logs, and HIPAA-enabled workspaces. Northflank is SOC 2 Type 2 and HIPAA compliant, with Enterprise BAAs. [Northflank RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control) covers granular permissions, project restrictions, roles, directory groups, and scoped API access. Audit logs span organization-to-resource scopes; SAML or OIDC SSO and directory sync centralize identity. [Northflank Enterprise](https://northflank.com/docs/v1/application/enterprise) adds contractual uptime guarantees, engineering support, infrastructure audit events, custom disaster recovery, and forward-deployed or air-gapped control planes. Northflank BYOC puts the cloud account and runtime-data boundary under customer control. Render retains a vendor-operated infrastructure boundary. ## How do Northflank and Render compare on pricing and total cost of ownership? Render combines a workspace subscription with metered resources. Northflank Cloud uses granular resource pricing; Northflank BYOC combines platform and cloud-provider charges. Prices and plans are current as of 25 August 2026. - **Render:** Hobby is $0, Pro is $25 per month flat, Scale is $499 per month flat, and Enterprise uses custom pricing. Pro and Scale include unlimited members. Compute, datastores, persistent disks, preview resources, and usage above included bandwidth or build-minute allowances are billed in addition to the workspace subscription. - **Northflank:** The free Sandbox includes always-on compute, two services, one database, and two cron jobs. [Pay-as-you-go](https://northflank.com/pricing) is self-service, includes teams without seat fees, and is billed per second; Northflank Cloud costs $0.01667 per vCPU-hour and $0.00833 per GB-hour. Enterprise uses custom invoice-based pricing with volume discounts and commitments, adding SSO, audit logs, HA/DR, on-premises deployment, 24/7 support, SLAs, and FDE onboarding. With BYOC, your provider bills infrastructure directly while Northflank charges $0.01389 per vCPU-hour, $0.00139 per GB-hour, and $0.00278 per GB of GPU VRAM-hour, while preserving access to cloud credits and commitments. - **Total cost of ownership:** Both reduce operational work through different models. Render operates the infrastructure. Northflank abstracts Kubernetes while preserving deeper control, including in BYOC. Custom resource plans, request modifiers, node-pool autoscaling, spot nodes, workload scheduling, and separate build capacity can improve utilization. Include Northflank's BYOC cluster minimum in capacity planning. ## When should you choose Render over Northflank? Choose Render when your application fits its managed service model and reducing infrastructure decisions is more valuable than controlling the underlying cloud. - Your architecture is mainly static sites, web services, private services, workers, cron jobs, Postgres, and a Redis-compatible store. - You want frontend and backend services on one vendor-managed PaaS without operating or sizing Kubernetes. - Render's Pro or Scale packaging covers your collaboration, audit, SSO, networking, and compliance requirements. - Your required regions, instance types, private connectivity, and scaling limits fit Render's operating boundary. ## When should you choose Northflank over Render? Northflank fits enterprise platform teams and growing organizations that need self-service delivery with workload, governance, and infrastructure control. - Your workloads must run in your cloud account, an eligible public-cloud Kubernetes cluster, or qualified on-premises or bare-metal infrastructure. - CPU services and optional GPU workloads need one deployment and operations layer. - Your architecture includes several database, cache, queue, job, service, and storage types. - Your developers need self-service delivery while the platform team retains custom resource plans, cluster scheduling, autoscaling, and granular network controls. - You want to begin on managed cloud without designing a different developer workflow for later BYOC or BYOK adoption. - Cloud commitments, data residency, specialized compute, or customer VPC deployments make direct infrastructure billing and cost-efficient capacity control valuable. ## Northflank vs Render: final decision Render fits conventional web stacks that stay within its vendor-operated infrastructure model. Northflank fits enterprise and platform teams that want direct developer workflows plus one control plane for broader workloads and managed or customer-controlled infrastructure. Test a representative API, job, datastore, preview, private dependency, observability export, expected scale, and monthly cost before committing. ## Frequently asked questions about Northflank vs Render ### Is Northflank better than Render? Northflank supports conventional web applications as well as mixed workloads, BYOC or BYOK, optional GPUs, and deeper controls. Render fits web stacks that remain within its managed service and infrastructure model. ### Is Render easier to use than Northflank? Render presents fewer infrastructure choices. Northflank provides Git-to-deploy while letting teams add workload, release, and infrastructure controls when needed. ### Which is better for GPU workloads? Northflank supports GPU workloads directly through managed-cloud GPU plans and BYOC GPU node pools for services and jobs. As of 25 August 2026, Render does not offer GPU instances. ### Which is better for BYOC? Northflank provides BYOC and BYOK. BYOC provisions Kubernetes in your cloud account; BYOK imports an eligible cluster. Account for minimum capacity, billing, data boundaries, and retained responsibilities. ### Which platform is better for enterprise teams? Render suits enterprises whose requirements fit its managed PaaS boundary. Northflank is designed for enterprises needing Kubernetes abstraction, governed developer self-service, BYOC or private infrastructure, granular controls, and forward-deployed options. ### Which is cheaper, Northflank or Render? It depends on the workload. Render adds a workspace plan to compute, datastores, disks, previews, traffic, and optional features. Northflank Cloud meters compute, storage, and traffic; Northflank BYOC adds platform fees to your cloud-provider costs. Compare a real topology rather than one instance rate. ## Related articles about deployment platform selection - [Is Render suitable for enterprise deployments?](https://northflank.com/blog/is-render-suitable-for-enterprise-deployments) - [Best Render alternatives](https://northflank.com/blog/render-alternatives) - [What is a deployment automation platform?](https://northflank.com/blog/deployment-automation-platform) - [Best cloud hosting platforms](https://northflank.com/blog/best-cloud-hosting-platforms) - [What is the best global PaaS with multi-region deployments?](https://northflank.com/blog/global-paas-with-multi-region-deployments)

How regulated enterprises can run AI agent sandboxes securely

2026-08-25T16:15:00.000Z

## TL;DR: how regulated enterprises can run AI agent sandboxes - **Strong isolation**: Run each agent session in an isolated microVM to limit the impact of generated or untrusted code on the host, adjacent workloads, and other agent sessions. - **Data residency and infrastructure control**: Keep agent execution and the data it processes within infrastructure and regions your organization controls. Use BYOC or a forward-deployed control plane - **Network controls**: Restrict outbound access. Define which internal services the sandbox can reach. Block everything else by default. - **Auditability**: Log every agent action, sandbox creation, execution event, and network request with a timestamp and identity. Export to SIEM. - **Secrets management**: Inject credentials per session at runtime. Never persist secrets inside the sandbox. Rotate centrally. > [Northflank](https://northflank.com/) runs isolated AI-agent sandboxes using Kata Containers, Firecracker, and gVisor alongside your applications and databases, in [Northflank's managed cloud](https://northflank.com/features/managed-cloud) or inside your own infrastructure with [self-serve BYOC](https://northflank.com/product/bring-your-own-cloud). [Get started (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > AI agents can write and execute code, install dependencies, access APIs, and interact with files and services. For a regulated enterprise, giving an agent this level of access is not simply a developer tooling decision. The environment where the agent runs becomes part of the security architecture. A secure AI sandbox needs to contain the agent while giving it enough access to do useful work. Enterprises also need to consider where data is processed, what the agent can access, how credentials are provided, and whether activity can be audited. These requirements become particularly important when agents work with sensitive data or operate inside regulated environments. ## Why standard sandbox approaches fail regulated enterprises The most common mistake enterprises make when deploying AI agents is treating agent execution like any other containerized workload. Standard Docker containers share the host kernel. Every container on the node makes system calls to the same kernel. A successful container escape can allow code running inside the container to access the host and potentially compromise other workloads, depending on the runtime configuration and available privileges. At that point, every other container on the node, every secret mounted to any container, and the underlying cloud instance are all compromised. For a regulated enterprise running agent workloads alongside production services, that blast radius may be unacceptable for regulated workloads. The second failure is infrastructure location. Most managed sandbox platforms run agent workloads on shared vendor infrastructure. For enterprises with data residency requirements, healthcare organizations whose agents process protected health information, financial institutions with network isolation mandates, and government agencies whose workloads cannot leave a specific infrastructure boundary, a managed platform where execution happens on the vendor's servers is not a viable option. The controls that matter are not in the sandbox software. They are in where the sandbox runs, who can see what it does, and what it can reach from inside. ## The five infrastructure controls regulated enterprises need There is no universal checklist that makes an AI sandbox compliant for every organization. The controls required depend on the data, workload, threat model, jurisdiction, and regulatory requirements. These five areas provide a practical starting point for evaluating a secure AI sandbox. ### 1. Kernel-level isolation per agent session The isolation model is one of the most important decisions in an enterprise AI sandbox architecture. Strong isolation means each agent session runs within its own security boundary rather than sharing the host kernel directly with other workloads. With a microVM, each session has its own kernel, memory space, filesystem, and network stack. **Kata Containers** and **Firecracker** use virtualization to provide this type of isolation, while **gVisor** provides an additional software isolation layer between workloads and the host kernel. Each approach has different tradeoffs around isolation, compatibility, startup time, and resource overhead. For regulated workloads, untrusted agent code should not share the same security boundary as the host or other sensitive workloads. Sandboxes should also be ephemeral, with the isolated environment created when the agent session starts and removed when it ends. This prevents state, files, and processes from one session from being exposed to another. ### 2. Data residency and VPC deployment Data residency for AI agents means more than choosing a cloud region. Enterprises need to know where agent execution happens, where processed data and logs are stored, and whether any data crosses a network boundary they did not authorize. This is particularly important for healthcare, financial services, and government workloads that may have specific requirements around data location and infrastructure. The deployment model determines how much control an enterprise has over this boundary. **BYOC** can run sandbox workloads inside the enterprise's own cloud account and VPC, allowing existing network and data controls to apply. A forward-deployed control plane can provide even greater infrastructure control for environments with strict connectivity or deployment requirements. The exact requirements depend on the workload and applicable regulations, so data residency should be treated as one part of the overall security architecture rather than a compliance guarantee by itself. ### 3. Secrets management and per-session credential injection AI agents need credentials to access databases, APIs, internal services, and other tools. Storing long-lived credentials directly inside sandbox configurations increases the risk of accidental exposure and makes credentials harder to rotate across many concurrent sessions. Instead, credentials should be stored outside the sandbox and provided only when the agent needs them. Per-session credential injection allows the platform to provide each agent with only the credentials required for its task. Credentials should follow least-privilege principles and be scoped as narrowly as possible. When a session ends or a credential needs to be rotated, it can be revoked or replaced centrally without rebuilding every sandbox. ### 4. Network isolation and egress control An isolated execution environment still needs network controls. Without them, an agent may be able to reach internal services, cloud resources, or the public internet from inside the sandbox. For enterprise workloads, network access should therefore follow a default-deny model, where the sandbox can only reach destinations that have been explicitly allowed. Useful controls include egress allowlists for approved external endpoints, private networking for agent-to-service communication, blocking access to cloud metadata endpoints that could expose instance credentials, and restricting communication between individual agent sessions. These controls limit what an agent can reach if its code is compromised, manipulated through prompt injection, or otherwise behaves unexpectedly. ### 5. Audit logging for every agent action A regulated enterprise needs to be able to reconstruct what happened during an agent session. Audit logs should capture events such as who or what created the sandbox, when the session started and ended, which tools were used, which commands were executed, which resources were accessed, and which network activity occurred. Events should include timestamps and session or user identities so they can be correlated during an investigation. Platform-level logging is particularly important because it does not depend entirely on the agent or application code producing its own logs. These events should be exportable to the organization's SIEM for centralized monitoring, investigation, and retention. The required retention period and level of detail will depend on the organization's security policies and applicable regulatory requirements. ## How Northflank provides enterprise-grade sandboxes [Northflank](https://northflank.com/) is a runtime platform for running AI agent sandboxes alongside applications, databases, and GPU workloads. Sandboxes can run in Northflank's managed cloud, in your own infrastructure through BYOC, or with a forward-deployed control plane inside your environment. - [**Sandbox isolation**](https://northflank.com/product/sandboxes): Each agent session runs in an isolated environment using Kata Containers with Cloud Hypervisor, Firecracker, or gVisor. The isolation technology can be selected based on workload requirements, with each execution receiving its own dedicated kernel where supported. A compromised execution is isolated from adjacent workloads and the host. In the [ComputeSDK 2026 Scale Invitational](https://platform.computesdk.com/scale-invitational), Northflank reached 100,000 concurrent sandboxes in 24 seconds from a cold start with zero failures, with P99 allocation at 566ms and P99 readiness at 733ms. - **Infrastructure and data control**: [Northflank BYOC](https://northflank.com/product/bring-your-own-cloud) deploys the Northflank data plane into your AWS, GCP, Azure, Oracle, CoreWeave, Civo, on-premises Kubernetes, or bare-metal infrastructure. Agent workload runtime and data remain inside your own cloud environment. The [forward-deployed control plane](https://northflank.com/enterprise) moves the entire platform, including the control plane and audit database, into your environment with no external dependencies, supporting environments with strict connectivity requirements, including air-gapped networks. - [**Secrets management**](https://northflank.com/docs/v1/application/secure/security-on-northflank#secret-management): Northflank secret groups securely manage credentials and inject selected secrets into sandbox workloads at runtime. Secrets can be managed and rotated centrally rather than embedded directly in application code or images. - [**Enterprise security**](https://northflank.com/enterprise). Northflank provides RBAC at the organisation, project, and environment level, alongside SAML and OIDC SSO integrations. Network policies can restrict sandbox access to explicitly configured services and resources. Audit logs capture sandbox creation, execution events, secret access, and configuration changes with timestamps and identity, and can be exported to an enterprise SIEM for centralized retention and monitoring. - **Application and sandbox infrastructure in one platform**: Agent sandboxes, the application that orchestrates them, and the databases and services those agents need to access can run within the same Northflank platform. This gives teams a single runtime platform for managing both their application infrastructure and agent execution environments. Northflank is SOC 2 Type 2 certified across managed cloud and BYOC deployments, and a HIPAA BAA is available on request for eligible healthcare workloads under enterprise agreements. ## Conclusion Regulated enterprises do not necessarily need to avoid AI-agent sandboxes. They need to treat the sandbox as part of the security architecture around the agent. Strong workload isolation, controlled network access, appropriate identity and secrets management, data residency, and auditability all contribute to a safer execution environment. The right architecture depends on the workload and the organization's requirements. For teams that need to run AI agents inside controlled infrastructure, Northflank provides isolated sandbox environments and BYOC deployment options, giving enterprises greater control over where and how their workloads run. [Get started with Northflank](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ## FAQ: secure AI-agent sandboxes for regulated enterprises ### What is an AI-agent sandbox? An AI-agent sandbox is an isolated environment for running code generated or executed by an AI agent. It separates agent execution from the host, other workloads, and other agent sessions, limiting what the agent can access or affect. The sandbox can be created for a session and removed when the session ends. Northflank provides isolated sandboxes for running AI-generated code alongside your applications and infrastructure. ### Why do AI agents need stronger isolation than containers? Containers share the host kernel, so a successful container escape can potentially affect the host and other workloads on the same node. MicroVM-based isolation gives each agent session a stronger security boundary, reducing the impact of compromised or malicious code. Northflank supports multiple sandbox isolation technologies, including Kata Containers and Firecracker. ### Can AI-agent sandboxes run inside a private VPC? Yes. Northflank BYOC lets you run sandbox workloads in your own cloud infrastructure and VPC, giving you control over where workloads and data are processed. For environments with stricter infrastructure requirements, Northflank also supports a forward-deployed control plane. ### How should enterprises handle credentials inside AI-agent sandboxes? Credentials should be managed outside the sandbox and provided only when they are needed. Use a secrets manager to inject credentials at runtime, scope them to the minimum permissions required, and rotate them centrally. Northflank provides secret groups for managing credentials used by applications and sandbox workloads. ### How can enterprises audit what an AI agent did? Use platform-level audit logs to record sandbox activity, configuration changes, and other infrastructure events with timestamps and identities where supported. These logs can be combined with application-level agent traces and exported to your existing monitoring or SIEM systems for investigation and retention. ### Is a sandbox enough to make an AI application compliant? No. A sandbox is one security control within a broader security and compliance architecture. Enterprises also need appropriate access controls, encryption, data handling policies, vendor agreements, monitoring, and organizational processes. A sandbox can reduce the blast radius of an incident, but it does not by itself establish compliance with HIPAA, PCI DSS, FedRAMP, or other regulatory frameworks. ## Related articles - [Best enterprise AI sandbox platforms](https://northflank.com/blog/best-enterprise-ai-sandbox-platforms) - [How to secure AI agents in the cloud](https://northflank.com/blog/how-to-secure-ai-agents-in-the-cloud) - [What are computers for AI agents?](https://northflank.com/blog/what-are-computers-for-ai-agents) - [Best IDP for highly regulated industries](https://northflank.com/blog/what-is-the-best-idp-for-highly-regulated-industries)

How to design networking for secure AI-agent sandboxes

2026-08-25T16:15:00.000Z

## TL;DR: how to design networking for AI-agent sandboxes - **Default-deny egress:** block outbound traffic by default and explicitly allow only the destinations an agent needs - **Egress allowlists:** define permitted destinations by hostname, IP, port, and protocol rather than by what to block - **DNS controls:** restrict which domains sandboxes can resolve and prevent DNS from becoming a path around egress policy - **Private networking:** route sandbox-to-service traffic through private VPC paths, not public endpoints - **Per-tenant network policy**: apply network policies at the tenant, project, or environment level so one agent cannot reach another tenant's resources > [Northflank](https://northflank.com/) is a runtime platform that runs isolated AI-agent sandboxes with [configurable network policies](https://northflank.com/docs/v1/application/network/configure-network-policies) that support deny-all egress and explicit allowlists, [private connectivity](https://northflank.com/docs/v1/application/network/enable-multi-project-networking) to services running in the same platform or VPC, and [self-serve BYOC](https://northflank.com/product/bring-your-own-cloud) so sandbox workloads run inside your own cloud network. [Get started (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > AI agents need network access to be useful. They install packages, call external APIs, access databases, communicate with internal services, and fetch information from the internet. The problem is that an agent can use that same network access to reach resources it was never supposed to reach, or exfiltrate data to an unauthorized destination. The design principle that follows from this is simple: give the sandbox the minimum network access required to perform its task and deny everything else. What makes this hard is working out what "minimum" means in practice, how to enforce it reliably, and how to extend it consistently across tenants, environments, and VPC resources. This guide covers the network controls that answer those questions. ## Why compute isolation alone is not enough A microVM gives each agent session its own kernel, its own memory space, and its own filesystem. A compromised or manipulated execution inside the microVM cannot directly access the host or adjacent workloads. That is the compute isolation guarantee, and it is a necessary starting point. But compute isolation answers only one question: what can this program access on the machine where it runs? It says nothing about what the program can reach beyond the machine. A perfectly isolated microVM with unrestricted network access can still exfiltrate data to an attacker-controlled endpoint, probe internal services that are reachable from the VPC, reach the cloud instance metadata service to steal credentials, install malicious dependencies that phone home, or respond to prompt injection by calling an unauthorized destination. Isolation without egress control contains the process. It does not contain the process's consequences. Both controls are required. ## The five network controls for AI-agent sandboxes A secure AI sandbox should give agent code access only to the network resources it needs. The core controls are default-deny egress, explicit allowlists, DNS controls, private networking, and per-tenant network policies. ### 1. Default-deny egress The starting point for AI sandbox networking is to block outbound traffic by default and explicitly allow only the destinations an agent needs to reach. This limits the damage caused by unexpected or malicious code, whether an agent tries to contact an unapproved API, download a package from an unknown source, or exfiltrate data to an external endpoint. The network policy should enforce the allowlist independently of the agent. The agent should not be able to modify its own network permissions. For workloads that need package installation or external APIs, allow only the required registries, services, and endpoints rather than granting unrestricted internet access. ### 2. Egress allowlists and credential brokering An egress allowlist defines exactly where a sandbox can connect. Policies can restrict traffic by hostname, IP range, port, and protocol, depending on how much control the workload requires. A proxy can provide hostname-level controls for outbound requests, while firewall or network policies can enforce broader restrictions at the IP and port level. For sensitive credentials, enterprises can also keep tokens outside the sandbox and use a credential brokering pattern. Instead of injecting a real API key into the agent environment, an external proxy can authenticate the request, attach the required credential, and forward it to the approved destination. This means the sandbox does not need to hold long-lived credentials that untrusted or AI-generated code could access. ### 3. DNS controls DNS needs to be part of the sandbox's network policy. An agent with unrestricted DNS access can resolve unapproved domains and potentially use DNS as a channel for data exfiltration. If internal DNS also exposes names for sensitive services, unrestricted resolution can reveal information about the internal network. DNS controls should also prevent sandboxes from bypassing the resolver through services such as DNS-over-HTTPS. Internal services should use private DNS names that resolve only within the appropriate VPC or network, rather than requiring the sandbox to connect through publicly exposed endpoints. ### 4. Private networking and VPC access Sandbox-to-service traffic should use private network paths wherever possible. Databases, internal APIs, queues, and other services should be reachable through private IP addresses and DNS rather than being exposed to the public internet simply so an agent can access them. Running sandboxes inside a VPC does not automatically give them unrestricted access to everything in that VPC. Network policies, security groups, and other controls should limit each sandbox to the specific services and subnets it needs. In a BYOC deployment, this allows enterprises to apply their existing VPC controls to sandbox workloads while keeping sensitive services off the public internet. ### 5. Per-tenant network policy Multi-tenant AI platforms should apply network policies at the tenant or project level rather than using one global policy for every sandbox. Each tenant should have an explicit allowlist that determines which external endpoints and internal services its sandboxes can reach. The same principle should apply across environments. A development sandbox may be allowed to access development databases and APIs, while a production environment should have a separate policy. This prevents one tenant or environment from using an otherwise valid network path to reach another tenant's services or sensitive infrastructure. ## Reference architecture: secure AI agent sandbox networking A simple secure AI sandbox network might look like this: ![image.png](https://assets.northflank.com/image_b7e1918f44.png) A typical architecture puts the sandbox behind a default-deny egress policy while using private networking to connect it to only the internal services it needs. ## Common AI sandbox networking mistakes - **Allowing unrestricted internet egress**: An agent with unrestricted outbound access can exfiltrate data, contact attacker-controlled infrastructure, or download untrusted dependencies. Start with default-deny egress and allow only the destinations the sandbox actually needs. - **Giving every sandbox the same network policy**: A global policy can allow one tenant or environment to reach another tenant's services or sensitive infrastructure. Apply policies at the tenant, project, or environment level to keep network access isolated. - **Putting internal services on public endpoints**: Exposing a database or internal API through a public endpoint just so a sandbox can reach it unnecessarily increases the attack surface. Use private networking and internal DNS for sandbox-to-service communication. - **Treating VPC membership as an access grant**: A sandbox being inside a VPC does not mean it should be able to reach every resource within it. Use security groups and network policies to limit access to the specific services and subnets the sandbox needs. - **Ignoring DNS when designing egress controls**: IP-based egress rules are less effective if the sandbox can freely resolve and connect to unapproved domains or bypass the approved resolver. Restrict DNS resolution and design DNS policies alongside your egress controls. - **Not logging denied connections**: Blocked requests can reveal prompt injection attempts, compromised dependencies, unexpected agent behaviour, or misconfigured policies. Logging denied traffic gives security teams visibility into what the sandbox tried to reach, even when the request was blocked. ## How Northflank handles sandbox networking [Northflank](https://northflank.com/) is a runtime platform for running AI-agent sandboxes alongside applications, databases, and other services. It gives teams the networking controls needed to isolate sandbox workloads, restrict what they can reach, and connect them to private infrastructure. - [**Sandbox isolation**](https://northflank.com/product/sandboxes): Run untrusted agent code in isolated microVM-backed environments, providing the compute isolation that network policies build on. - [**Network policies**](https://northflank.com/docs/v1/application/network/configure-network-policies): Configure deny-all egress and explicit allowlists to control which services and endpoints sandbox workloads can reach at the project and workload level. This lets you apply the same network isolation principles without building the policy layer yourself - [**Private networking**](https://northflank.com/docs/v1/application/network/enable-multi-project-networking): Connect sandboxes to applications, databases, and other services over private internal networks without requiring those services to be publicly exposed. - [**BYOC**](https://northflank.com/product/bring-your-own-cloud) and [**forward-deployed deployments**](https://northflank.com/enterprise): With Bring Your Own Cloud, sandbox workloads can run in your own AWS, GCP, Azure, or other supported infrastructure, allowing your existing VPC, subnet, and network security controls to apply. For stricter requirements, Northflank can also run within your own environment through a forward-deployed control plane, including deployments designed for limited or no external connectivity. - [**Secrets management**](https://northflank.com/docs/v1/application/secure/manage-secret-groups): Use secrets management to securely manage credentials used by sandbox workloads without embedding them directly into the sandbox configuration. - [**Enterprise security**](https://northflank.com/enterprise): [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [SSO](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication), and [audit logging](https://northflank.com/docs/v1/application/observe/audit-logs) provide access control and visibility across the platform, helping teams govern who can access and manage sandbox workloads. The advantage is that you do not need to assemble a separate networking layer around your sandbox infrastructure. Northflank brings the sandbox runtime, applications, databases, private networking, and enterprise security controls together in one platform, so you can enforce how agent workloads communicate without managing each component separately. [Get started with Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ## Conclusion Secure AI sandbox networking is about giving agents the connectivity they need while limiting everything else. Default-deny egress, explicit allowlists, controlled DNS, private access to internal services, and per-tenant policies reduce the paths an agent can use to reach unrelated infrastructure or exfiltrate data. These controls are most effective when enforced at the infrastructure layer, where they apply regardless of what code the agent generates or executes. For teams that want to run isolated AI-agent sandboxes alongside their applications and private infrastructure, [Northflank](https://northflank.com/) provides the runtime, networking, and BYOC capabilities to build this architecture without assembling a separate sandbox networking stack. ## FAQ: AI sandbox networking ### What is AI sandbox networking? AI sandbox networking controls what an AI agent can access over the network while it executes code. It typically includes egress policies, destination allowlists, private service connectivity, DNS controls, and network isolation between workloads or tenants. ### What are sandbox egress controls? Sandbox egress controls restrict outbound connections from an agent's execution environment. A default-deny policy blocks traffic unless a destination is explicitly allowed, reducing the risk of data exfiltration, unauthorized service access, and connections to malicious infrastructure. ### Should AI-agent sandboxes have internet access? They can have internet access when the agent needs it, but unrestricted access is usually unnecessary. A better approach is to allow only the domains, IP ranges, ports, or services required by the workload and deny everything else by default. ### How can an AI sandbox access private services? An AI sandbox can access private services through a private network or VPC connection rather than a public endpoint. Network policies, routing rules, and firewall controls should then restrict the sandbox to only the internal services it needs. ### How do you isolate network access between AI-agent tenants? Apply network policies at the tenant, project, environment, or sandbox level so each workload receives only the destinations it is authorized to reach. For a multi-tenant platform, Tenant A's sandbox should not be able to route to Tenant B's applications, databases, or other private resources. ## Related articles - [How regulated enterprises can run AI-agent sandboxes securely](https://northflank.com/blog/how-regulated-enterprises-can-run-ai-agent-sandboxes-securely) - [How to secure AI agents in the cloud](https://northflank.com/blog/how-to-secure-ai-agents-in-the-cloud) - [Best enterprise AI sandbox platforms](https://northflank.com/blog/best-enterprise-ai-sandbox-platforms)

How to scale AI-agent sandboxes for high-concurrency workloads

2026-08-24T16:32:00.000Z

A sandbox API can work for ten agents and fail when thousands start together. Admission, networking, storage, scheduling, or cleanup may bottleneck first. Scaling AI-agent sandboxes requires a bounded execution architecture. This guide covers demand, bursts, tenant isolation, lifecycle, cost, failure testing, and enterprise operations. ## TL;DR: How to scale AI-agent sandboxes for high-concurrency workloads Scale AI-agent sandboxes by separating admission from placement, keeping capacity ready for bursts, and dividing the fleet into bounded cells as demand grows. - Define live concurrency, starts per second, time to interactive, active duration, and resource shape before setting a scale target. - Enforce tenant quota and safe-capacity checks before placement. Queue bounded work and reject excess demand rather than oversubscribing the fleet. - Keep hosts, common images, filesystems, networking, and credentials ready enough to meet the complete startup objective. - Make create, pause, resume, expire, and delete operations asynchronous and retry-safe. Cleanup is part of capacity management. - Combine runtime isolation with resource limits, network policy, scoped credentials, priority, and independent containment. If your enterprise needs isolated execution at high concurrency, [Northflank](https://northflank.com/) is a full-stack application platform with API-driven [Sandboxes](https://northflank.com/product/sandboxes) for ephemeral or persistent environments using microVM or gVisor isolation. The same platform runs APIs, workers, databases, storage, and GPU workloads. Northflank has operated millions of microVMs monthly since 2021. In the 18 June 2026 [ComputeSDK Scale Invitational](https://platform.computesdk.com/scale-invitational), Northflank reached 100,000 concurrent live 1-vCPU sandboxes in 24 seconds. Enterprise teams can use SSO, RBAC, scoped API roles, secret injection, private networking, and audit logs to govern access across the sandbox fleet and surrounding services. Start on [Northflank Cloud](https://northflank.com/cloud/northflank), or use self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud) when workloads need to run in your cloud account with its network, regional, capacity, and billing controls. Compatible coding agents can use [Northflank Skills](https://github.com/northflank/skills) to operate sandboxes and related infrastructure within their assigned permissions. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, isolation, concurrency, cloud placement, or migration requirements. ## What does high concurrency mean for AI-agent sandboxes? High concurrency means many isolated environments are live at once, but that number alone does not describe the workload. Track five dimensions: - **Live concurrency:** environments consuming runtime capacity now. - **Start throughput:** environments admitted per second during a burst. - **Time to interactive:** time from request acceptance until useful work can begin. - **Active duration:** how long an environment consumes compute before it pauses or terminates. - **Resource shape:** CPU, memory, storage, network, process, and GPU requirements per sandbox. Workload shape changes the decision. Short executions stress creation and cleanup; persistent workspaces retain memory and storage; browser agents use heavier images; evaluation or RL workers create large batches. A large monthly execution count may produce modest concurrency, while ten thousand starts in one minute can stress every provisioning dependency. ## Which architecture scales AI-agent sandboxes under burst demand? A scalable architecture keeps global admission separate from local placement and runtime operation. ### 1. Global admission and tenant quotas Admission authenticates the caller, authorizes the workload, checks quota, selects a region or cell, and assigns a durable sandbox ID. Require an idempotency key so retries do not create duplicate environments. When capacity is unavailable, use a bounded queue with a deadline and expose its state. Once full, return a retry signal. An unbounded queue converts a capacity event into unpredictable latency and cost. Quota should cover starts per second, CPU, memory, storage, network use, process count, lifetime, and retained idle environments, not only live sandbox count. If each workload needs defined compute resources, Northflank [resource plans](https://northflank.com/docs/v1/application/scale/scale-cpu-and-memory) let you assign CPU and memory to it, while [horizontal autoscaling](https://northflank.com/docs/v1/application/scale/autoscale-deployments) sets minimum and maximum deployment instances. Your sandbox control plane should enforce tenant-wide concurrency and creation-rate limits before sending work for placement. The [secure AI-generated code platform comparison](https://northflank.com/blog/best-platform-running-ai-generated-code-securely-at-scale) explains how resource controls fit alongside isolation and lifecycle requirements. ### 2. Cell-local placement and failure isolation After admission selects a cell, a local scheduler should place the sandbox on a host with the required runtime, capacity, image, storage path, and topology. A cell is a bounded group of clusters or hosts with its own capacity and failure radius. Kubernetes v1.36's [large-cluster guidance](https://kubernetes.io/docs/setup/best-practices/cluster-large/) describes an envelope of 5,000 nodes and 150,000 pods, while cloud quotas may constrain growth sooner. Add cells when a cluster approaches safe tested capacity, control-plane pressure affects readiness, workloads need separate runtimes, or one failure would affect too many tenants. Keep detailed runtime state local so a global service does not process every status update. If your enterprise needs sandbox workloads inside its own cloud account, Northflank BYOC provides the deployment model and supports [sandboxed node pools, tags, and affinity rules](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-in-your-cloud). These controls separate pools by runtime, region, tenant tier, or hardware. For a larger cell architecture, see [how to run millions of concurrent AI sandboxes](https://northflank.com/blog/how-to-run-millions-concurrent-ai-sandboxes). ### 3. Warm capacity and image locality Fast runtime boot does not help if hosts, images, filesystems, networking, or credentials still need provisioning. Keep the slowest parts outside the startup path. This includes ready hosts, pre-pulled images, cached layers, prepared filesystems, IP space, gateways, and credential capacity. Separate pools so a large GPU image does not delay a small code interpreter. Warm capacity should cover net concurrency growth during infrastructure provisioning plus a failure reserve. Measure cache misses and cold-host starts separately. ### 4. Asynchronous lifecycle reconciliation Sandbox creation should return an operation or ID before readiness. A controller then reconciles accepted, starting, ready, paused, terminating, and deleted states. Make every transition retry-safe. Use leases to expire abandoned environments, and record deletion so late events cannot recreate them. Cleanup must remove compute, routes, temporary credentials, and ephemeral storage. A fleet that creates 1,000 sandboxes per second but deletes only 900 will exhaust capacity. If agents need programmatic lifecycle control, Northflank exposes [sandbox creation and lifecycle operations](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank), including startup, status inspection, command execution, pause, resume, and deletion through its JavaScript client. ### 5. External state and shared gateways Keep orchestration state outside the sandbox and make root filesystems disposable where the workload permits. Put durable files in persistent volumes or object storage, then associate them with a stable sandbox or workspace identity. If files must survive a restart or pause, Northflank [sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) support [persistent volumes](https://northflank.com/docs/v1/application/databases-and-persistence/add-a-volume). A Single Read/Write volume limits the attached service to one instance, while Multi Read/Write supports multiple replicas but requires coordination for concurrent writes. See when to use [persistent or ephemeral AI sandboxes](https://northflank.com/blog/persistent-vs-ephemeral-ai-sandboxes). Avoid creating a public load balancer or IP for every environment. Shared regional gateways can authenticate requests and route them to private sandbox endpoints, reducing infrastructure objects and centralizing rate limits and access checks. ## How should you plan capacity for high-concurrency sandbox workloads? Plan capacity using workload-shaped load tests rather than a generic sandbox-density number. Measure live concurrency, peak creation rate, resource requirements, and the time required to add usable infrastructure. Keep enough ready capacity to absorb demand during that provisioning interval, plus the failure reserve required by your availability objective. Capacity is bounded by whichever part of the execution path saturates first. Admission throughput, scheduler and control-plane throughput, host CPU and memory, storage, networking, image distribution, credentials, and external services can each become the limiting factor. Autoscaling replenishes capacity, but it still depends on provider quotas, node creation, image preparation, and cluster registration. Ready capacity covers the interval before new infrastructure becomes usable. If the execution fleet must run in your cloud account, Northflank BYOC places the workloads there and lets platform teams [deploy and scale node pools](https://northflank.com/docs/v1/application/bring-your-own-cloud/deploy-and-scale-node-pools) while retaining workload quotas and placement rules. ## How do you prevent noisy neighbours and cross-tenant risk? Prevent cross-tenant risk by applying isolation and resource policy at the same boundary used for admission and scheduling. Use hardware-virtualized microVMs or an appropriate user-space-kernel boundary for untrusted model-generated or user-submitted code, based on your threat model. Runtime isolation does not limit what code can reach or consume, so add: - Per-sandbox CPU, memory, process, storage, network, and duration limits - Tenant-level concurrent sandbox and creation-rate quotas - Default-deny sandbox-to-sandbox networking where communication is unnecessary - Destination and protocol controls for egress - Short-lived credentials scoped to one task and the minimum required actions - Priority classes and reserved capacity for critical workloads Containment must work independently of the agent. Operators need to terminate a run, revoke credentials, block network access, quarantine state, and stop another request. Test those actions under load. If sandbox traffic must remain private or reach only approved destinations, Northflank provides [private connections](https://northflank.com/docs/v1/application/network/networking-on-northflank#private-networking) between workloads. On BYOC, configure [Network Policies](https://northflank.com/docs/v1/application/network/configure-network-policies) as allow-lists or deny-all rules; without relevant rules, traffic is allowed. Combine them with [secret injection](https://northflank.com/docs/v1/application/secure/inject-secrets) and [scoped API roles](https://northflank.com/docs/v1/application/secure/grant-api-access). See how to [isolate AI agents that access company data](https://northflank.com/blog/how-to-isolate-ai-agents-with-company-data) for the wider authorization model. ## Which metrics show whether an AI-agent sandbox fleet is scaling? A sandbox fleet is scaling when it meets readiness, isolation, cleanup, and cost objectives under expected bursts. Measure: - **Admission:** accepted, queued, rejected, deduplicated, and rate-limited requests - **Readiness:** queue time, placement time, runtime boot, image preparation, network setup, and time to interactive at median and tail percentiles - **Capacity:** live sandboxes, ready headroom, host utilization, unschedulable requests, and pool or cell saturation - **Runtime:** forced termination, resource-limit events, command failures, and network-policy denials - **Lifecycle:** pause, resume, expiry, deletion success, cleanup lag, and orphan count - **Cost:** compute and storage per sandbox-minute, task, tenant, and workload class Break metrics down by region, cell, runtime, and tenant tier. Keep sandbox or user IDs in queryable logs instead of metric labels. Platform audit logs show who or what changed platform resources. Application telemetry should record policy-permitted inputs and outputs, tool activity, approvals, affected resources, and state changes without requiring private chain-of-thought. If platform teams need one operational view, Northflank's built-in observability provides workload [logs and metrics](https://northflank.com/docs/v1/application/observe/observability-on-northflank), infrastructure alerts, and separate [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) for platform events. ## How should you test a high-concurrency sandbox platform? Test the complete agent workflow at the burst shape you expect in production, then remove dependencies and capacity deliberately. Use the real image, dependencies, network policy, credentials, storage, and readiness check. Increase creation rate and concurrency separately to distinguish provisioning bottlenecks from steady-state limits. During the test: 1. Exhaust a tenant quota and confirm other tenants retain capacity. 2. Remove hosts or a cell and measure admission and recovery. 3. Force image-cache misses and slow storage dependencies. 4. Deny egress and revoke a credential during execution. 5. Delete a large batch and confirm compute, routes, credentials, and temporary data disappear. 6. Retry create and delete requests to confirm idempotency. In the 18 June 2026 [ComputeSDK Scale Invitational](https://platform.computesdk.com/scale-invitational), Northflank reports reaching 100,000 concurrent live 1-vCPU sandboxes in 24 seconds; ComputeSDK records a matching 100,000+ 1-vCPU run. Test your images, dependencies, networking, storage, and readiness path under the concurrency and burst shape you expect. For an implementation starting point, follow the guide to [spin up a secure code sandbox and microVM](https://northflank.com/blog/how-to-spin-up-a-secure-code-sandbox-and-microvm-in-seconds-with-northflank-firecracker-gvisor-kata-clh), then replace its sample workload with your production image and burst profile. ## How does Northflank scale AI-agent sandboxes for high-concurrency workloads? Northflank brings the controls used throughout this architecture together with the surrounding stack. Teams can control isolated sandboxes through the [REST API](https://northflank.com/docs/v1/api/use-the-api), [CLI](https://northflank.com/docs/v1/api/use-the-cli), or [JavaScript client](https://northflank.com/docs/v1/api/use-the-javascript-client), while applying SSO, RBAC, scoped API roles, secrets, and audit logs. Compatible coding agents can use [Northflank Skills](https://github.com/northflank/skills) to operate sandboxes and related infrastructure through the same interfaces within their assigned permissions. With [Northflank Cloud](https://northflank.com/cloud/northflank), Northflank provides managed infrastructure. With self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud), your enterprise owns the cloud account and infrastructure while Northflank manages platform orchestration. Available sandbox runtimes depend on the cloud provider and region. Northflank has operated millions of microVMs monthly since 2021. For enterprise security and procurement requirements, Northflank is [SOC 2 Type 2 compliant and HIPAA compliant](https://northflank.com/security), with BAAs supported under Enterprise contracts. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss sandbox architecture, concurrency, isolation, BYOC capacity, or migration. ## Frequently asked questions about scaling AI-agent sandboxes These answers cover scaling decisions. ### Is concurrency the same as sandbox starts per second? No. They measure different things: concurrency counts live environments, while starts per second measures creation throughput. Long-running workspaces can have high concurrency and a low start rate; short tasks can produce the opposite pattern. ### Do you need multiple Kubernetes clusters for high-concurrency sandboxes? Not immediately. Start with one tested cell, then add cells when capacity, control-plane pressure, workload separation, regional placement, or failure radius requires it. Northflank supports managed [Northflank Cloud](https://northflank.com/cloud/northflank) and sandbox deployment through [BYOC](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-in-your-cloud). ### How much warm capacity should you keep? Keep enough ready capacity for demand during infrastructure provisioning, plus the failure reserve your SLO requires. Load tests determine the number. For customer-cloud fleets, Northflank BYOC lets teams [deploy and scale node pools](https://northflank.com/docs/v1/application/bring-your-own-cloud/deploy-and-scale-node-pools). ### Does sub-second microVM boot guarantee sub-second sandbox readiness? No. MicroVM boot is only one stage. Time to interactive also includes admission, queues, placement, images, filesystems, networking, credentials, process startup, and health checks. ### Can autoscaling alone handle a sandbox burst? Not on its own. Northflank [horizontal autoscaling](https://northflank.com/docs/v1/application/scale/autoscale-deployments) can add deployment instances based on configured CPU, memory, RPS, or custom-metric thresholds. Admission control, quotas, ready capacity, image preparation, provider limits, and cleanup still determine whether a burst succeeds safely. ## Related articles about AI-agent sandbox infrastructure - [How to run millions of concurrent AI sandboxes](https://northflank.com/blog/how-to-run-millions-concurrent-ai-sandboxes) - [Which platform is best for running AI-generated code securely at scale?](https://northflank.com/blog/best-platform-running-ai-generated-code-securely-at-scale) - [Persistent vs ephemeral AI sandboxes](https://northflank.com/blog/persistent-vs-ephemeral-ai-sandboxes) - [How to isolate AI agents that have access to company data](https://northflank.com/blog/how-to-isolate-ai-agents-with-company-data) - [What is sandbox infrastructure?](https://northflank.com/blog/what-is-sandbox-infrastructure)

How to govern AI-agent code execution in enterprise environments

2026-08-24T16:31:00.000Z

An AI agent can move from suggesting code to running shell commands, installing dependencies, changing files, and calling internal services in one workflow. Risk appears when that temporary execution inherits a developer's credentials, a shared worker's network access, or a path to production. Governance needs to cover the complete execution event, not only the model's response. This article explains how to control who starts a run, what enters it, where it executes, what it can reach, what evidence it produces, and how your operators stop it. ## TL;DR: How to govern AI-agent code execution Govern AI-agent code execution by putting every run inside a policy-controlled, isolated, time-bound environment with scoped identity, data, networking, resources, evidence, and containment. - Register each execution path with an owner, approved purpose, target environments, tools, data classes, network destinations, resource limits, and shutdown procedure. - Authorize each run from its initiating identity, agent identity, requested action, code provenance, target, and delegated authority. - Run generated or untrusted code away from the agent orchestrator and shared application workloads, using a boundary proportionate to the risk. - Issue short-lived credentials and allow only the files, secrets, services, and external destinations required for that task. - Record policy decisions and effects, then test escape, escalation, exfiltration, persistence, and approval-bypass paths before increasing autonomy. If your enterprise needs agents to execute code without placing the orchestrator, production services, or company network inside the same trust boundary, [Northflank](https://northflank.com/) combines isolated [sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) with scoped API access, secret injection, private networking, audit logs, preview environments, and release workflows. Run the execution layer on [Northflank Cloud](https://northflank.com/cloud/northflank), or use self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud) when workloads need to run in your cloud account with its network and infrastructure controls. [Northflank Skills](https://github.com/northflank/skills) helps compatible coding agents use the platform's API and CLI to create and operate sandboxes and the services around them. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## What does governing AI-agent code execution mean? Governing AI-agent code execution means enforcing the conditions under which an agent may run code, from admission through termination. An enforceable policy layer outside the agent should decide whether execution is permitted and constrain environment creation, access, limits, and evidence retention. Use the following execution classes as a practical framework, not a fixed industry standard: | Execution class | Example | Minimum control level | | --- | --- | --- | | Analysis only | Parse a supplied file without network access | Ephemeral workspace, no credentials, strict resource and lifetime limits | | Build and test | Install dependencies and run tests for a pull request | Isolated runtime, approved registries, restricted egress, non-production secrets | | Bounded internal action | Query an approved service or update a development resource | Named identity, task-scoped credential, target allowlist, policy checks and evidence | | Production-impacting execution | Run a migration, deployment, or operational command | Independent authorization, separation of duties, digest-bound input, rollback and incident controls | Treat transitions between classes as new authorization decisions. Passing sandbox tests should not grant permission to deploy the result. ## Which controls should apply before an agent runs code? Before execution, establish ownership, verify the request, and decide whether the code and its inputs are eligible to run at all. ### 1. Register the execution path and owner Inventory agents that can invoke a shell, interpreter, build system, notebook, or execution API. Record the owner, approved job, environments, tools, data classes, destinations, persistence, runtime, and containment procedure. Inventory the route, not just the product. Local, CI, and support agents can create different identity and network paths. If execution classes need harder network boundaries, Northflank lets your platform team separate workloads into [self-contained projects](https://northflank.com/docs/v1/application/network/enable-multi-project-networking). This creates an organizational and default network boundary without treating project placement as authorization. ### 2. Authorize the run, not only the agent Authenticate the initiator, then evaluate the agent's narrower authority against the operation, code origin, target, affected resources, data class, and time window. Do not let an agent inherit a developer session or shared administrator token. An agent testing a branch does not need production database or organization access. If agent access needs to follow enterprise identity policies, Northflank supports [SAML or OIDC SSO, directory sync, and MFA enforcement](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation). Your platform team can use [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control) and scoped [API roles](https://northflank.com/docs/v1/application/secure/grant-api-access) to control which projects and actions each identity can reach. See [secure enterprise agent deployment](https://northflank.com/blog/how-to-deploy-agents-securely-in-enterprises) for the wider architecture. ### 3. Validate code, images, and dependencies Treat code, commands, images, manifests, build scripts, repositories, and tool responses as inputs. Establish provenance where practical, pin approved artifacts, and use controlled registries. Treat repository files, tickets, webpages, logs, tool responses, and retrieved documents as potentially adversarial instructions. Authorize the resulting operation, not the source of the instruction. Run secret, dependency, image, and static checks when they fit the workload. Scanning can find known problems, but it cannot prove that generated code is safe. Runtime containment remains necessary. For functional review, a [Northflank Preview Blueprint](https://northflank.com/docs/v1/application/release/manage-preview-blueprints) creates an isolated full-stack deployment for a branch or pull request. This connects execution governance to a [separate development and production path](https://northflank.com/blog/separate-development-production-vibe-coded-apps). ## How should the runtime contain agent-generated code? The runtime should assume the code may be wrong or hostile and constrain its effect independently of model behavior. ### 1. Use an execution boundary matched to the risk Run generated code outside the orchestrator and shared workers, with its own filesystem, resources, lifecycle, and identity. A conventional container may suit a low-risk, single-tenant task with trusted code and tightly restricted inputs and privileges. Prompt-generated code, untrusted repositories, user files, or new dependencies may justify a separate-kernel boundary such as a microVM. Generated or untrusted code can run in [Northflank sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) with strong workload isolation on Northflank Cloud. Compare the wider [requirements for running AI-generated code securely at scale](https://northflank.com/blog/best-platform-running-ai-generated-code-securely-at-scale). ### 2. Keep credentials and data task-scoped Start without ambient credentials. After policy approval, issue short-lived access and inject only the secret, file, or dataset the task requires. Keep development and production credentials distinct. Give test runners sandbox integrations and approved test data. Scope access to a company service by operation and resource. For runtime credentials, [Northflank secret groups](https://northflank.com/docs/v1/application/secure/manage-secret-groups) inject selected values into specific workloads. Data authorization still belongs in the application, as explained in [how to isolate AI agents that access company data](https://northflank.com/blog/how-to-isolate-ai-agents-with-company-data). ### 3. Deny network access by default Begin with no inbound access and no unnecessary egress. Explicitly allow required registries, source hosts, model endpoints, and internal APIs. Keep cloud metadata services, cluster control planes, credential endpoints, production databases, and unrelated internal networks unreachable. Route required outbound actions through a controlled service when the destination or payload needs validation. Network policy cannot prevent prompt injection, but it can stop an injected command from reaching an unapproved target. If your execution layer runs in BYOC, configure Northflank [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies) as allowlists or deny-all rules. With no rules, traffic is allowed in that direction. This differs from default project isolation. For approved private routes, follow the same principles used to [connect AI-built applications to private corporate APIs](https://northflank.com/blog/connect-ai-built-app-private-apis-corporate-network). ### 4. Bound time, compute, storage, and persistence Set deadlines and CPU, memory, storage, process, and output limits to contain runaway processes and cost. Default to ephemeral storage. Persistent state needs an owner, retention period, access policy, and deletion path. Termination should remove the runtime and revoke access. For resumable state, Northflank sandboxes can attach a volume and manage compute and storage separately. Compare the lifecycle choices in [persistent versus ephemeral AI sandboxes](https://northflank.com/blog/persistent-vs-ephemeral-ai-sandboxes). ## Which agent actions need approval? Approval should follow authority and impact, not interrupt every agent action. Policy can allow low-risk tests in a restricted sandbox. Medium-risk operations may require checks against an approved repository, command family, environment, and change window. Use independent authorization for production deployments, destructive data changes, privileged identity changes, secret access, disabling security controls, or multi-tenant effects. Show the versioned artifact or proposed operation, target, effective permissions, expected effect, and recovery path. Bind approval to that operation and expire it to prevent replay. If agent-generated changes need a controlled route to production, [Northflank Workflows](https://northflank.com/docs/v1/application/release/configure-workflows) can connect builds, deployments, jobs, backups, conditions, and proportionate approvals. This keeps authority in the release process rather than the agent session. ## What should enterprises log and test? Enterprises should retain enough evidence to reconstruct why a run was allowed, what it did, and what changed without collecting unnecessary sensitive content. Correlate the initiator, agent and policy version, artifact digest, environment, policy decision, credentials, destinations, commands, approvals, affected resources, result, resource use, and termination reason. Record inputs and outputs only where policy permits, without chain-of-thought. Application traces should capture policy-relevant action selections, tool calls, tool results, and execution outcomes. Platform audit logs should capture access, infrastructure, build, and deployment changes. Connect them with a run or trace ID. If your security team needs the platform side of that evidence, Northflank [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) record event type, triggering identity, source, timestamp, parent events, and resource-scoped platform changes. Agent commands and tool results still require application traces. Before widening access, test malicious inputs, prompt injection, malformed commands, escalation, secret discovery, disallowed egress, resource exhaustion, persistence, approval bypass, replay, and sandbox escape. Use the results to decide whether authority can increase. ## How should you stop unsafe agent execution? Containment must operate independently of the agent and the systems it controls. Your operators should be able to terminate the runtime, revoke issued credentials, block its network paths, disable the relevant tool or policy, quarantine persistent state, preserve evidence, and prevent another run from starting. Test this sequence while a task is active, including the behavior of child processes and asynchronous jobs. Stopping the model does not stop every effect. Queued deployments, background processes, issued tokens, or external API requests may outlive the conversation and require separate containment. If each run needs an independent lifecycle, a Northflank sandbox can be paused by scaling it to zero or destroyed through the API, with persistent volumes removed separately when the incident procedure permits it. ## How does Northflank govern AI-agent code execution? Northflank brings the controls used throughout this article into one platform for agent sandboxes and the APIs, jobs, databases, and release workflows around them. [Northflank for Enterprise](https://northflank.com/enterprise) adds the organization-level identity and governance layer, while your application retains responsibility for deciding which command, tool, or business record an agent may use. Teams can create sandboxes through the [Northflank API](https://northflank.com/docs/v1/api/use-the-api) or [JavaScript client](https://northflank.com/docs/v1/api/use-the-javascript-client), restrict access with [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), control BYOC egress through [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies), and correlate [platform audit events](https://northflank.com/docs/v1/application/observe/audit-logs) with agent traces. [Preview environments](https://northflank.com/docs/v1/application/release/manage-preview-blueprints) and [Workflows](https://northflank.com/docs/v1/application/release/configure-workflows) give validated outputs a separate route to production. Use [Northflank Cloud](https://northflank.com/cloud/northflank) for managed infrastructure. If workloads need to run inside your cloud account with its network controls and regional placement, use [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud). Workloads run in your cloud environment, while Northflank-hosted control-plane metadata remains outside that workload boundary. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss execution architecture, isolation, access, networking, data boundaries, and migration requirements. ## Frequently asked questions about governing AI-agent code execution These answers address common decisions when enterprises introduce agent-controlled runtimes. ### Is a container enough for AI-agent code execution? It depends on the code and impact. A container may suit low-risk, single-tenant automation with trusted code and restricted inputs and privileges. Generated or untrusted code may require a separate-kernel boundary. Northflank provides [sandboxes with strong workload isolation](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) on Northflank Cloud. ### Does every agent command need human approval? No. Low-risk, reversible commands can run under policy. Require independent authorization for higher-impact actions. Northflank [Workflows](https://northflank.com/docs/v1/application/release/configure-workflows) can add conditions and approvals to agent-generated releases. ### Does BYOC make agent execution safe? Not on its own. Northflank [BYOC](https://northflank.com/features/bring-your-own-cloud) runs agent workloads in your cloud environment, but you still need scoped access, isolation, egress controls, evidence, and containment. ### Can sandboxing prevent prompt injection? No. A sandbox does not stop a model from following malicious instructions. It limits the systems, credentials, files, network paths, and resources that manipulated code can reach, reducing the resulting blast radius. ## Related articles about secure AI-agent execution Use these guides to extend execution governance across data, deployment, environment design, and scale. - [How to isolate AI agents that have access to company data](https://northflank.com/blog/how-to-isolate-ai-agents-with-company-data) - [Which platform is best for running AI-generated code securely at scale?](https://northflank.com/blog/best-platform-running-ai-generated-code-securely-at-scale) - [How to deploy agents securely in enterprises](https://northflank.com/blog/how-to-deploy-agents-securely-in-enterprises) - [How enterprises should separate development and production for vibe-coded apps](https://northflank.com/blog/separate-development-production-vibe-coded-apps) - [How to run millions of concurrent AI sandboxes](https://northflank.com/blog/how-to-run-millions-concurrent-ai-sandboxes)

Which database strategy should you use for preview environments?

2026-08-24T14:15:00.000Z

# Which database strategy should you use for preview environments? ## TL;DR: Which database strategy should you use for preview environments? - **Isolated fork per PR:** Best for schema changes, migrations, and production-like testing. - **Copy-on-write branching:** Best for fast, isolated database previews with lower storage overhead. - **Shared database:** Best for simple previews that do not modify the schema or shared data. - **Seeded database:** Best for clean, reproducible previews that do not need production data. > [**Northflank**](https://northflank.com/) is a runtime platform for applications that lets you create isolated preview environments with their own databases. This makes it easier to test database changes and migrations without affecting other environments. You can also deploy it in your own cloud with [BYOC](https://northflank.com/product/bring-your-own-cloud) when you need more control over your infrastructure and data. [Get started with Northflank](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > Preview environments without databases are only half a test. You can spin up an isolated application, give it a live URL, and validate the UI, but if it shares a database with other pull requests, the results may not reflect what the application will actually encounter in production. The database strategy is where preview environments get more complicated. Databases carry state, so every approach involves a tradeoff between isolation, cost, migration safety, and how closely the preview reflects production. ## What is a database strategy for preview environments? A database strategy defines how each preview environment gets its database, what state that database starts in, and what happens to it when the environment is torn down. For stateless services, this is straightforward: clone the service configuration, point it at the new environment, and you're done. Databases are different because they carry state. Your strategy determines whether one PR's database changes can affect other previews, whether migrations run against realistic data or an empty schema, how much your preview environments cost as PR volume grows, and whether sensitive data ends up in a test environment. ## Why databases are harder than services in preview environments A service is configuration. A database is configuration plus data. That distinction drives every tradeoff in preview environment database strategy. - **The state problem:** When two PRs share a database, any change one makes is visible to the other. A migration run by PR-A changes the schema that PR-B is testing against. A seed script run by PR-A inserts rows that PR-B's tests did not expect. The more PRs are open simultaneously, the worse this interference becomes. - **The migration problem:** Schema migrations are one of the most important things to validate in a preview environment. A migration against an empty database does not reveal how it behaves with existing production-like data, while a migration against shared staging can affect other previews. An isolated copy of realistic data provides a safer way to test these changes. - **The data residency problem:** Using production data in preview environments creates compliance exposure. GDPR, HIPAA, and PCI DSS all have implications for where customer data can be processed and who can access it. A preview environment that pulls from a production backup and is accessible to a contractor reviewing a PR is a compliance event waiting to happen. - **The cost problem:** Full isolation, one database per PR, is the safest strategy. It is also the most expensive. At ten engineers with three open PRs each, you are running thirty concurrent database instances. The cost of doing this right has to be managed deliberately. ## Database strategies for preview environments The best database strategy depends on the type of changes you need to test and how closely your preview should reflect production. The four most common approaches are isolated database forks, copy-on-write branching, shared databases, and empty databases with seed data. ### Strategy 1: Isolated database fork per PR Every pull request gets its own database instance, created when the PR opens and removed when it merges or closes. The database can be forked from a backup of your staging or production database, giving the preview a realistic starting state. **How it works:** When a PR is opened, the preview platform creates a new database from an existing backup, runs any pending migrations on the isolated database, and connects it to the preview environment. When the PR closes, the database is removed. **Why it works:** Each PR has its own database, so changes cannot affect other previews or staging. Migrations can be tested against realistic data, while application and test data remain isolated between environments. **The tradeoffs:** The main constraint is cost. Each PR requires its own database instance, so costs increase with the number of concurrent previews. Automatic teardown, idle detection, and TTL rules can help control resource usage. **Best for:** PRs that change the database schema, applications that need strong data isolation, and teams that want to test migrations against realistic data. ### Strategy 2: Copy-on-write database branching Copy-on-write branching creates an isolated database branch without immediately duplicating all of the parent's underlying data. Changes made by the branch are stored separately, reducing the storage required for multiple database environments. **How it works:** A database branch is created from a parent database, typically staging or development. The branch starts with the parent's data and schema, while subsequent changes are isolated to the branch. **Why it works:** Branches can be created quickly and use less storage than independent database instances, making this approach useful when you need many concurrent preview environments. **The constraint:** Database branching depends on capabilities provided by the database platform. PostgreSQL platforms such as Neon provide copy-on-write branching, while other database types may require separate instances or different cloning strategies. **Best for:** Teams that use a database with native branching support and need fast, isolated previews without provisioning a full database instance for every PR. ### Strategy 3: Shared database per environment All preview environments connect to the same database, typically a shared staging database. No separate database is created for each PR. **Why teams use it:** It is the simplest and cheapest option. It can work well when previews mainly test frontend or application changes that do not modify the database schema. **Why it breaks down:** A migration from one PR changes the schema that every other preview is using. Changes to shared data can also affect tests and application behaviour in other environments, making previews less predictable as the number of concurrent PRs grows. **Making it safer:** Separate database schemas or PR-specific test data can reduce some conflicts, but these approaches add complexity and do not provide the same isolation as separate databases. **Best for:** Small teams, stable schemas, and preview environments where database changes are uncommon. ### Strategy 4: Empty database with seed data Each preview gets a fresh database populated with a known dataset when the environment starts. The seed data provides the minimum state required to run and test the application. **Why it works:** Every preview starts from a predictable state without copying data from another environment. This makes tests reproducible and avoids depending on whatever data happens to exist in staging. **The limitations:** Seed data may not reflect the volume or edge cases found in production. Maintaining seed scripts also becomes more difficult as the application's schema and data relationships evolve. **Best for:** Test-driven workflows, applications with simple data models, and teams that need deterministic preview data without copying production or staging data. ## How to choose a database strategy The right strategy depends on what the PR changes, how much database isolation you need, and whether the data can be used in preview environments. - **If the PR changes the schema or database logic:** use an isolated fork or copy-on-write branch. Both give the PR its own database, so migrations and database changes cannot affect other previews. Forks are a better fit when you need multiple database types or closer production parity. - **If the PR is frontend-only or does not change the database:** a shared staging database may be enough. Per-PR isolation adds cost and complexity when the application is not changing its database behaviour. - **If you handle regulated or sensitive data:** sanitise the source data before using it in preview environments. A common approach is to create a sanitised staging snapshot and use it as the source for database forks or branches. - **If you use PostgreSQL and want lower-cost isolation:** copy-on-write branching can create isolated databases without duplicating the entire dataset. This can be a good option for teams with many concurrent previews, although it depends on database platforms that support branching. - **If your application uses multiple database types:** consider how each database will be isolated. Forking PostgreSQL while sharing Redis, for example, still leaves session, cache, or queue state shared between previews. ## How Northflank handles database strategy for preview environments [Northflank](https://northflank.com/) is a runtime platform for applications that lets you provision isolated databases alongside each preview environment, so the application, database, and supporting services can be created and removed together. - **Database forking:** When a preview environment is created, its database can be forked from an existing database snapshot rather than sharing the staging database. This gives each preview its own database instance, so migrations and test data stay isolated from other environments. - **Preview blueprints:** You can define the application services, databases, configuration, and other resources in a reusable blueprint. When a PR creates a preview environment, the required resources are provisioned together and can be torn down when the preview is no longer needed. - **Teardown scheduling:** Preview environments can be configured to shut down during periods when they are not needed, such as nights and weekends. This helps reduce the resources running for inactive previews without requiring developers to delete them. - **Cost controls:** Teams can also use lifecycle policies such as automatic teardown after a defined period to prevent abandoned preview environments and their databases from running indefinitely. This becomes particularly useful as the number of concurrent PRs grows. - **Multiple database types:** Northflank supports PostgreSQL, MySQL, MongoDB, Redis, MinIO, RabbitMQ, and more, allowing the database layer to be included alongside the rest of the preview environment. - **BYOC:** If you need to keep preview infrastructure in your own cloud, [Northflank's BYOC](https://northflank.com/product/bring-your-own-cloud) model lets you deploy the environment into your own AWS, GCP, Azure, or on-premises infrastructure. **Build preview environments directly from AI coding workflows** Northflank can also be used from AI coding workflows to provision preview environments while you build. This lets an AI coding agent create the application environment, provision the required database, and deploy the changes without requiring you to manually configure the infrastructure for each preview. This is particularly useful for AI-generated applications, where each coding session can produce a working environment with its own application services and database for testing. - [How to set up preview environments for apps built with Claude Code](https://northflank.com/blog/how-to-set-up-preview-environments-for-apps-built-with-claude-code) - [How to set up preview environments for apps built with Codex](https://northflank.com/blog/how-to-set-up-preview-environments-for-apps-built-with-codex) - [How to set up CI/CD for a vibe-coded app](https://northflank.com/blog/how-to-set-up-ci-cd-for-a-vibe-coded-app) ## Conclusion The right approach depends on what the PR changes, how much isolation you need, and what data you can safely use in preview environments. Shared databases work for simple changes, seeded databases provide predictable test data, and isolated forks provide stronger production parity. Copy-on-write branching can offer a lower-cost alternative when your database supports it. For teams that need isolated databases alongside application services, CI/CD, and infrastructure, [Northflank](https://northflank.com/) provides the tooling to manage the entire preview environment together. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ## FAQ: database strategies for preview environments ### What is database forking in preview environments? Database forking creates a new database instance from an existing database snapshot. The fork starts with the same data and schema as the source but remains isolated, so changes do not affect the original database. In preview environments, this gives each PR its own database for testing migrations and data changes. ### What is the difference between database forking and database branching? Forking creates a separate database instance from a backup or snapshot. Database branching uses copy-on-write storage to create an isolated database without duplicating the underlying data. Branching can be faster and more storage-efficient, while forking can work across a wider range of database types. ### Can I run migrations safely in a preview environment? Yes. An isolated database lets each PR run migrations without affecting other previews or staging. Forking from staging also lets you test migrations against realistic data rather than an empty database. ### How much does a preview environment database cost? It depends on the strategy. Shared databases have no additional per-PR database cost, while isolated databases add cost for each active preview. Scheduling previews to shut down when they are not needed can help reduce those costs. [Northflank pricing calculator](https://northflank.com/pricing) can help estimate the cost based on your database type and size. ### What is the best database strategy for a multi-tenant application? Isolated databases are generally the safest option. Each PR gets its own data, so changes and test data from one preview cannot interfere with another tenant or environment. ### How should I handle GDPR or HIPAA-regulated data in preview environments? Do not use production data directly. Sanitise sensitive data first, then use the sanitised dataset as the source for preview databases. This preserves realistic data shapes while reducing the risk of exposing customer information in development and preview environments. ## Related articles - [How to auto-create preview environments on every PR](https://northflank.com/blog/how-to-auto-create-preview-environments-on-every-pr) - [Top managed database services](https://northflank.com/blog/top-managed-database-services) - [How to set up CI/CD for a vibe-coded app](https://northflank.com/blog/how-to-set-up-ci-cd-for-a-vibe-coded-app) - [Ephemeral preview environments for vibe-coded apps](https://northflank.com/blog/ephemeral-preview-environments-vibe-coded-apps)

How do preview environments scale for AI-generated code?

2026-08-21T14:24:00.000Z

One developer opening one pull request is easy to support. Hundreds of employees and coding agents generating changes throughout the day create a different problem. Every change may need a build, frontend, API, worker, database, secrets, URL, and test run. Manual provisioning creates a queue; copying production for every change creates cost and security problems. This article explains how preview environments scale for AI-generated code across provisioning, data, security, lifecycle, and cost. ## TL;DR: How preview environments scale for AI-generated code Preview environments scale when each change becomes bounded, declarative infrastructure. - Define the stack once in a reusable blueprint instead of assembling every preview manually. - Create or update one isolated environment per active change, not a new stack for every commit. - Provision only the services and data the change needs. - Put limits around build concurrency, active previews, resources, lifetime, and spend. - Use synthetic, seeded, or safely forked non-production data instead of copying production into every environment. - Delete the whole environment automatically when the pull request closes, merges, or becomes inactive. - Measure readiness time, failure rate, cost, cleanup lag, and review throughput. If your enterprise needs preview environments for AI-generated code, [Northflank](https://northflank.com/) can automatically provision an isolated full-stack environment for a pull request or branch using [Preview Blueprints](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints). A preview can include services, databases, jobs, volumes, secret groups, private networking, and unique URLs. Use Git events for pull requests, or create previews through webhooks, the API, and manual runs. Conditional blueprint nodes let you deploy only the parts of the stack a change needs, while concurrency limits, smaller resource plans, and automatic cleanup keep demand bounded. Run previews on [Northflank Cloud](https://northflank.com/cloud/northflank), or use self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud) when AI-generated code must run in your cloud account with its network, billing, and regional controls. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss preview concurrency, application architecture, cloud placement, security, or cost. ## Why do preview environments for AI-generated code need a different scaling model? AI changes the arrival rate and shape of software changes. A coding agent can open a pull request, read a failure, revise several files, and push again before a person finishes reviewing the first version. The code still needs to be built, tested, reviewed, and released, but [AI-generated code puts more work](https://northflank.com/blog/ci-cd-for-ai-generated-code) through every validation stage. A shared staging environment handles that demand poorly. Changes overwrite one another, tests compete for data, and broken migrations block other teams. Per-change previews restore parallelism only when provisioning and deletion are automatic. Think of demand as: `active previews × resources per preview + builds in progress + shared platform overhead` Reduce those terms by limiting active previews, making each preview smaller, skipping unaffected components, and shortening its lifetime. Scaling is not simply adding cluster nodes. ## How is scaling one preview environment different from scaling AI-generated code previews? There are two separate scaling problems. **Application scaling** is what happens inside one preview. If reviewers or load tests send more traffic, the service may need more instances or larger compute resources. **Fleet scaling** is what happens when many pull requests each need an environment. It includes trigger bursts, build queues, scheduling, databases, secrets, quotas, and teardown. Horizontal autoscaling can help a busy preview service, but it does not stop 500 full-stack previews from creating 500 databases. Fleet scaling needs admission control, selective provisioning, capacity planning, and lifecycle policy. Most functional previews can use smaller plans. Reserve production-sized resources for purpose-built performance and resilience tests. ## Which architecture lets preview environments scale for AI-generated code? A scalable design makes environment creation repeatable, keeps each environment appropriately small, and has an explicit response when demand exceeds capacity. ### Reusable blueprints for scaling AI-generated code preview environments Start with a declarative blueprint that defines the resources, relationships, configuration inputs, and teardown behavior for a common application pattern. The platform should be able to run it without a ticket or an engineer translating the pull request into infrastructure. Version the blueprint and review it like application code. Northflank can [use the Git branch's contents](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints), so a pull request can test a proposed change to its own preview definition. Provide approved patterns for a single service, a frontend plus API, and a stateful stack instead of forcing every app into one large template. ### Selective provisioning for full-stack preview environments An isolated preview does not have to duplicate the whole company platform. It should duplicate the mutable resources and dependencies required to test the change safely. For a frontend change, reuse a stable non-production API. For an API change, create an isolated data store. For a cross-service schema change, provision the complete path, migration job, and database. Northflank Preview Blueprints support [condition nodes and skipped node execution](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints). In a monorepo, you can avoid creating unaffected services or select a lightweight mock based on the branch or trigger. This directly reduces scheduling work, startup time, and cost. The guide to [ephemeral testing environments](https://northflank.com/blog/ephemeral-testing-environments) explains how automated-test environments differ from previews intended for human review. One environment can serve both purposes. ### Build controls for AI-generated code preview environments Separate building from running. Cache dependencies safely, build each commit once where possible, and deploy the immutable image instead of rebuilding it for every test stage. Bound concurrent builds independently of active previews. A burst should create a visible queue, not exhaust capacity or delay production releases. Northflank [updates an existing preview on new commits](https://northflank.com/docs/v1/application/release/manage-preview-blueprints), so an agent's fifth revision does not leave four live environments behind. ### Data strategies for scalable preview environments Databases often determine preview cost and readiness time. Choose the lightest data strategy that can establish the behavior you need: | Preview data strategy | Best use | Main constraint | | --- | --- | --- | | Fresh schema with fixtures | Unit, integration, and common workflow tests | May miss production-shaped edge cases | | Synthetic dataset | Repeatable business and permission scenarios | Requires maintained generators | | Snapshot or fork of non-production | Migration and realistic query testing | Storage, freshness, and sensitive-data controls | | Shared read-only test service | Frontend or stateless consumer changes | Isolation is weaker and test state can collide | Do not attach previews to production. If production-shaped records are necessary, minimize and mask them through an approved process. A Northflank preview can include its own database addon, job, volume, and secret group. That gives a stateful change an isolated stack without making dedicated state mandatory for a static change. If the preview needs enterprise records, use the access and data controls in [connecting vibe-coded apps to company data securely](https://northflank.com/blog/connect-vibe-coded-apps-company-data-securely). ### Quotas and capacity for preview environments at scale Set limits at more than one layer: - Maximum previews per team, repository, or user - Maximum builds and creations in progress - Compute, storage, database, and replica limits per preview class - Maximum lifetime, inactivity period, and team spend Decide the admission policy before capacity fills. Production fixes may take priority, low-risk previews can queue, and unusually large environments can require approval. On Northflank, the preview guidance recommends [maximum concurrent preview limits, smaller plans, and automatic cleanup](https://northflank.com/docs/v1/application/release/manage-preview-blueprints). Services can [autoscale horizontally](https://northflank.com/docs/v1/application/scale/autoscale-deployments) within configured minimum and maximum instances. For BYOC, node pools and cluster autoscaling supply underlying capacity, but you should still retain workload quotas so a burst cannot expand spend without a bound. Cost scales with the number of active previews, their resource size, and how long they remain running. Use smaller plans for functional review, provision only affected components, cap concurrent previews and replicas, and delete environments on merge, close, or inactivity. Track cost alongside readiness time and review throughput; a cheap preview that nobody uses is not effective. ### Automatic teardown for AI-generated code preview environments Creation and deletion are one workflow. Tie teardown to pull-request close and merge, add inactivity expiry, and use a teardown workflow for external resources. Track cleanup lag and failures. Northflank can [delete previews on PR close, PR merge, or inactivity](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints). Preview resources are removed with it, while a teardown specification can remove related external resources. ## How do you secure preview environments for AI-generated code at scale? Apply security in the blueprint so the hundredth preview receives the same controls as the first. - Inject non-production secrets only into the resources that need them. - Give the automation identity permission to create previews, not to deploy production or read production credentials. - Keep internal services on private ports and expose only the review endpoint. - Authenticate preview URLs when the application or test data is not public. - Restrict egress to approved destinations where your infrastructure supports it. - Record who or what created, updated, and deleted the environment. - Scan dependencies and secrets, run tests, and require review; a successful deployment is not a security verdict. Northflank tags preview resources, and [secret groups scoped to that tag](https://northflank.com/docs/v1/application/release/manage-preview-blueprints) are available only within the preview by default. Combine this with [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [scoped API roles](https://northflank.com/docs/v1/application/secure/grant-api-access), [private networking](https://northflank.com/docs/v1/application/network/configure-ports#private-ports), and [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) that include preview template runs and their source. If the application executes generated code, packages, or commands at runtime, a preview is not the execution boundary. Use an appropriate sandbox; see the platforms for [running AI-generated code securely at scale](https://northflank.com/blog/best-platform-running-ai-generated-code-securely-at-scale). If a preview needs a private corporate API, give it a narrowly scoped non-production path rather than copying production reachability. See how to [connect AI-built apps to private APIs](https://northflank.com/blog/connect-ai-built-app-private-apis-corporate-network) for routing, workload identity, authorization, and testing controls. ## How does Northflank scale preview environments for AI-generated code? Northflank gives platform teams a repeatable way to provision full-stack preview environments for every AI-generated change without manually assembling infrastructure. The same blueprint can create isolated services, databases, jobs, secrets, networking, and URLs on Northflank Cloud or inside your own cloud, then update the environment as the pull request changes and remove it automatically when review ends. - **Define the environment once:** [Preview Blueprints](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) describe services, databases, jobs, volumes, secrets, networking, and teardown visually or as code. - **Trigger previews from your existing workflow:** Create previews from pull requests, branch pushes, webhooks, API calls, or manual runs. [New commits update the existing pull-request preview](https://northflank.com/docs/v1/application/release/manage-preview-blueprints) instead of creating another environment. - **Give each change an isolated stack:** Each preview receives its own resources and unique URLs, with [private ports](https://northflank.com/docs/v1/application/network/configure-ports#private-ports) for communication between internal components. - **Avoid provisioning unnecessary resources:** Use [conditions and skipped node execution](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) to omit unaffected services, deploy mocks, or vary the stack according to the repository, branch, or trigger. - **Bound resource use:** Choose smaller preview plans, set [maximum concurrent-preview limits](https://northflank.com/docs/v1/application/release/manage-preview-blueprints), cap [service autoscaling](https://northflank.com/docs/v1/application/scale/autoscale-deployments), and [monitor spending](https://northflank.com/docs/v1/application/billing/monitor-spending). - **Remove environments automatically:** Configure [automatic cleanup](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) when a pull request closes, merges, or becomes inactive, with teardown actions for external resources. - **Observe the preview fleet:** View preview status and metadata alongside build and runtime [logs and metrics](https://northflank.com/docs/v1/application/observe/observability-on-northflank). Keep application test results separate from platform audit events. - **Apply enterprise access controls:** Combine [preview-scoped secret groups](https://northflank.com/docs/v1/application/release/manage-preview-blueprints), [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [SAML or OIDC SSO](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation), [scoped API roles](https://northflank.com/docs/v1/application/secure/grant-api-access), and [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs). - **Choose where previews run:** Use [Northflank Cloud](https://northflank.com/cloud/northflank), or deploy through [BYOC](https://northflank.com/features/bring-your-own-cloud) when previews need to run in your AWS, GCP, Azure, or other supported infrastructure with your capacity and network controls. - **Work from the coding agent:** Install [Northflank Skills](https://github.com/northflank/skills) so compatible agents can create and operate preview environments through Northflank’s [CLI](https://northflank.com/docs/v1/api/use-the-cli) and [API](https://northflank.com/docs/v1/api/use-the-api) while remaining subject to their assigned platform permissions. Your team still decides which patterns are approved, which data may enter previews, how much concurrency to allow, and which checks block a merge. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss preview architecture, expected concurrency, BYOC capacity, security controls, and migration. ## Which metrics show whether preview environments for AI-generated code scale? Test a burst resembling your coding-agent workflow, including repeated commits and cross-service changes. Measure: - Trigger-to-ready time, including build and capacity queues - Creation and update failure rate - Concurrent previews and resources per preview - Repeated build work per commit - Cost per active hour and merged change - Teardown time, failures, and orphan count - Reviewer time to first feedback - Changes that bypass the preview path Also exhaust the preview quota, break a migration, revoke the automation credential, remove capacity, and close many pull requests at once. Confirm the system fails visibly, preserves production capacity, and removes everything it created. ## Frequently asked questions about preview environments for AI-generated code ### Does every AI-generated code change need a full-stack preview environment? No. Match it to the change and risk. Documentation may need no runtime, a frontend may reuse a test API, and a schema change may need services, jobs, and isolated state. Conditional blueprints select the required path. ### Should preview environments for AI-generated code use production data? Not by default. Prefer fixtures or synthetic data. If production-shaped records are necessary, use an approved, minimized, masked snapshot or fork. Never give previews production credentials. ### Can autoscaling alone scale preview environments for AI-generated code? No. Autoscaling adds service instances or cluster nodes; it does not control how many environments, databases, or builds are created. You still need quotas, selective provisioning, admission policy, and teardown. ### Can AI agents create their own preview environments for AI-generated code? Yes, if the platform exposes a controlled API or CLI and the agent has a scoped identity. Let the agent create or update previews and read relevant non-sensitive logs without giving it production release or secret access. Northflank supports Git, webhook, API, CLI, and Skills-based workflows for this model. ### Are preview environments enough to secure AI-generated code? No. They isolate validation from shared staging and production, but code review, scanning, tests, scoped secrets, network policy, and release gates still apply. If the application executes newly generated or user-supplied code at runtime, use a sandbox designed for that execution. ## Related articles about preview environments and AI-generated code - [Using ephemeral preview environments to test your vibe-coded apps](https://northflank.com/blog/ephemeral-preview-environments-vibe-coded-apps) - [Ephemeral testing environments](https://northflank.com/blog/ephemeral-testing-environments) - [CI/CD for AI-generated code: what changes and what stays the same](https://northflank.com/blog/ci-cd-for-ai-generated-code) - [How to build an enterprise platform for deploying AI-generated applications](https://northflank.com/blog/build-enterprise-ai-application-platform) - [How to deploy AI-built applications securely in your own cloud](https://northflank.com/blog/securely-deploy-ai-applications-in-your-cloud)

Which platforms support AI-agent sandboxes in a customer’s own cloud?

2026-08-21T14:22:00.000Z

AI agents that write code, install packages, process files, or call tools need a trusted execution boundary. With private data or services, vendor-hosted sandboxes may not fit your network, residency, or infrastructure policies. “Private,” “dedicated,” and “in your VPC” can describe different architectures. This article compares platforms that run sandbox compute on customer-owned infrastructure and helps you identify the boundary you need. ## TL;DR: Which platforms support AI-agent sandboxes in a customer’s own cloud? The platforms below support AI-agent sandbox execution in customer-owned cloud environments, but they place different parts of the platform inside that boundary. - **Northflank Sandboxes** lets you run microVM-backed or gVisor-isolated AI-agent sandboxes in your own cloud with enterprise infrastructure control through [self-serve BYOC](https://northflank.com/features/bring-your-own-cloud), with Northflank provisioning and managing Kubernetes, or on eligible existing private, on-premises, and bare-metal Kubernetes clusters through [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements). BYOC supports Google Cloud Platform, AWS, Microsoft Azure, Civo, Oracle Cloud, CoreWeave, and Nebius, while [Northflank Cloud](https://northflank.com/cloud/northflank) provides the fully managed option. - **E2B** provides API-driven Firecracker microVM sandboxes with contact-led BYOC for customer AWS and GCP environments. Templates, snapshots, runtime logs, and sensitive sandbox traffic remain within the customer VPC boundary. - **Runloop Devboxes** uses dedicated microVMs and a BYOC deployment that places the sandbox control plane and data plane in your AWS, GCP, or Azure environment. If your enterprise needs to run AI-agent sandboxes inside its own security, network, residency, or cloud-spend boundary, [Northflank Sandboxes](https://northflank.com/product/sandboxes) provide separate-kernel isolation on [Northflank Cloud](https://northflank.com/features/managed-cloud), self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud), or eligible existing Kubernetes through [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements). Northflank manages the platform and can provision and manage the Kubernetes layer in your cloud account, so your platform team retains infrastructure control without building the sandbox orchestration layer itself. Sandboxes run alongside APIs, workers, databases, storage, jobs, and GPU workloads with shared deployment, networking, secrets, observability, RBAC, and audit controls. Northflank is SOC 2 Type 2 compliant and HIPAA compliant, with BAAs supported under Enterprise contracts. [Northflank Skills](https://github.com/northflank/skills) also gives compatible coding agents Northflank-specific guidance for deploying and operating the platform. Startups and engineers can use the same capabilities through Northflank’s self-serve developer experience. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss AI-agent sandbox architecture, BYOC, Kubernetes, networking, security, compliance, or scale. ## What counts as an AI-agent sandbox in your own cloud? An own-cloud AI-agent sandbox runs its execution plane in a cloud account, VPC, Kubernetes cluster, or machine fleet your organization owns or manages. The vendor may still provide a hosted control plane, API, orchestration, or support. That excludes several useful but different designs. A service can attach to your VPC while executing elsewhere. Peering connects networks, a dedicated region isolates vendor capacity, and a custom image changes the environment rather than its location. Start by asking where agent-written code actually executes, then trace templates, snapshots, files, logs, credentials, and network traffic separately. If the main requirement is reaching internal services rather than owning the execution plane, the available patterns for [connecting AI-built applications to private APIs](https://northflank.com/blog/connect-ai-built-app-private-apis-corporate-network) may solve the problem without BYOC. ## How should you compare customer-cloud AI-agent sandbox platforms? Compare the boundary and the work your team must own, not just SDK syntax or startup time. 1. **What runs in your infrastructure?** Separate compute, storage, logs, and networking from the vendor control plane. 2. **What isolates each run?** Shared-kernel containers, user-space kernels, microVMs, and dedicated VMs provide different boundaries. This [guide to isolating AI agents with company data](https://northflank.com/blog/how-to-isolate-ai-agents-with-company-data) covers the surrounding controls. 3. **What state survives?** Disposable tasks and long-running coding agents have different needs. Compare the [trade-off between persistent and ephemeral AI sandboxes](https://northflank.com/blog/persistent-vs-ephemeral-ai-sandboxes). 4. **How does it reach other systems?** Check private DNS, egress policy, workload identity, secrets, and traffic paths. 5. **Who operates the fleet?** Self-hosting can leave upgrades, capacity, patches, storage, observability, and incident response with your team. ## How do customer-cloud AI-agent sandbox platforms compare? The best fit depends on which platform components must run in your account and whether you need a sandbox API or the complete infrastructure around your agents. | Platform | Best for | Customer-cloud boundary | Isolation | Operating model | | --- | --- | --- | --- | --- | | Northflank Sandboxes | Running sandboxes with the complete production agent stack | Sandbox workloads on BYOC or eligible BYOK Kubernetes | MicroVM-backed or gVisor user-space-kernel isolation, depending on configuration | Northflank manages the platform and can manage the BYOC cluster | | E2B | Running agent code in API-driven microVM sandboxes in a customer VPC | AWS and GCP | Firecracker microVM | E2B control plane with contact-led BYOC onboarding | | Runloop Devboxes | Keeping both sandbox planes in the customer environment | Control and data planes in AWS, GCP, or Azure | Dedicated microVM | Enterprise BYOC deployment | ## Which AI-agent sandbox platforms run in your own cloud? The following profiles explain how each platform fits a different customer-cloud operating model. ### 1. Northflank Sandboxes Northflank supports isolated AI-agent execution whether you are building a dedicated sandbox product or integrating sandboxes into a wider production platform. [Northflank Sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) provide separate-kernel isolation, command execution, exposed ports, persistent volumes, GPUs, pause, resume, and deletion. Northflank is built for enterprise infrastructure, security, and governance requirements, while startups and individual engineers can also use the same self-serve UI, [API](https://northflank.com/docs/v1/api), [CLI](https://northflank.com/docs/v1/api/use-the-cli), [SDK](https://northflank.com/docs/v1/api/use-the-javascript-client), [GitOps](https://northflank.com/docs/v1/application/infrastructure-as-code/gitops-on-northflank), and [templates](https://northflank.com/docs/v1/application/infrastructure-as-code/create-a-template). Your team can run sandboxes on [Northflank Cloud](https://northflank.com/cloud/northflank) or deploy them into infrastructure you control. [Self-serve BYOC](https://northflank.com/features/bring-your-own-cloud) places workloads in your cloud account with Northflank provisioning and managing Kubernetes, while [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements) lets you import a suitable existing Kubernetes cluster. Northflank also runs the infrastructure around the sandbox. APIs, workers, jobs, databases, object storage, persistent volumes, and GPU workloads use the same deployment and operations layer. An agent can create an environment, access a private service, store an artifact, trigger a job, and promote an output without your team combining separate sandbox and application platforms. The deployment and operations capabilities include: - **Self-serve BYOC:** Deploy into Google Cloud Platform, AWS, Microsoft Azure, Civo, Oracle Cloud, CoreWeave, or Nebius, with Northflank managing Kubernetes in your account. - [**BYOK**](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements): Import suitable existing Kubernetes, including eligible private, on-premises, or bare-metal infrastructure. - **Full-stack infrastructure:** Run APIs, workers, jobs, databases, storage, and GPU workloads with your sandboxes instead of operating separate platforms. - **Security and governance:** Use [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies), [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), scoped API roles, SAML or OIDC SSO, secret injection, and [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs). - **Compliance:** Northflank is [SOC 2 Type 2 compliant and HIPAA compliant](https://northflank.com/security), with BAAs supported under Enterprise contracts. - **Agent-native operations:** [Northflank Skills](https://github.com/northflank/skills) guides Codex, Claude Code, Cursor, and other compatible agents through Northflank workflows. With BYOC, workload runtime and data stay in your environment. The [Northflank security details](https://northflank.com/security) explain the separate options for metadata, logs, builds, images, DNS, and backups. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss AI-agent sandbox architecture, BYOC, Kubernetes, networking, security, compliance, or scale. ### 2. E2B E2B fits applications that already have most of their production infrastructure and need a sandbox API for agent code execution. - **Infrastructure targets:** E2B BYOC supports customer AWS and GCP environments. - **Isolation:** Each E2B sandbox runs in a Firecracker microVM. - **Data boundary:** Templates, snapshots, and runtime logs are stored in the customer VPC. Sensitive traffic, including template build source files and sandbox traffic, goes directly from the client to the BYOC VPC without traversing E2B Cloud. - **Control plane:** E2B Cloud manages the platform and receives anonymized cluster CPU and memory metrics. An internal load balancer and VPC peering can keep sandbox traffic private. - **Access model:** BYOC is contact-led and requires a dedicated supported cloud environment. Sandbox compute runs in the customer environment while E2B operates the hosted control plane. ### 3. Runloop Devboxes Runloop Devboxes is suited to policies that require both platform planes inside infrastructure owned by your organization. - **Customer-cloud boundary:** Runloop BYOC places the control plane and data plane in a customer AWS account, GCP project, or Azure subscription. - **Isolation:** Devboxes run in dedicated microVMs with their own kernel, filesystem, and network namespace. - **Security controls:** The deployment includes customer-managed KMS, workload identity, audit logs, and network isolation. - **Private connectivity:** Available patterns include private links, VPC peering, transit networks, and VPNs. - **Access model:** BYOC is an enterprise-led deployment. Before committing, validate upgrade ownership, support access, telemetry, capacity, disaster recovery, and the exact cloud services deployed. ## Which customer-cloud AI-agent sandbox platform fits your requirements? The right platform satisfies your non-negotiable boundary with the least new infrastructure for your team to own. - Use **Northflank Sandboxes** when you need sandboxes and the surrounding production application platform across managed cloud, BYOC, or BYOK. - Use **E2B** when API-driven Firecracker microVM sandboxes in AWS or GCP are the priority and contact-led onboarding is acceptable. - Use **Runloop Devboxes** when both planes must be placed in a customer AWS, GCP, or Azure environment. Test the platform with a representative workflow. Create environments under burst load, terminate a compromised run, revoke its credentials, deny an unapproved destination, restore required state, and trace an action end to end. At high concurrency, model the scheduler, warm capacity, quotas, and failure domains described in this guide to [running millions of concurrent AI sandboxes](https://northflank.com/blog/how-to-run-millions-concurrent-ai-sandboxes). If an agent creates a service that must stay online, move the artifact through a controlled build and release path. See [how to deploy an AI agent from sandbox to production](https://northflank.com/blog/how-to-deploy-ai-agent-from-sandbox-to-production) for that lifecycle. ## Frequently asked questions about AI-agent sandboxes in a customer’s own cloud These answers clarify common deployment boundaries. ### Is VPC peering the same as running sandboxes in my cloud? No. Peering creates a private network path between environments, but it does not change who owns the sandbox compute. With [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud), the sandbox workload runs on Kubernetes provisioned in your cloud account; peering or an overlay is a separate connectivity decision. ### Does BYOC keep every sandbox-related data type in my account? Not automatically. Trace sandbox files, templates, snapshots, logs, metrics, source code, images, backups, credentials, and control-plane metadata. For Northflank BYOC, workload runtime and workload data sit in your environment, while the [Northflank security details](https://northflank.com/security) explain the boundaries and options for other data categories. ### Do agent sandboxes need microVM isolation? It depends on the workload and threat model. A microVM or another separate-kernel boundary is a strong default for untrusted, tenant-supplied, or agent-generated code. [Northflank Sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) use separate-kernel isolation, while a hardened shared-kernel container may fit lower-risk internal tasks after you assess privilege, network access, credentials, and escape impact. ### Is self-hosting cheaper than a managed sandbox platform? It depends on utilization and operational cost. Include idle capacity, engineering, upgrades, security response, observability, and availability instead of comparing one vCPU rate. A managed BYOC model such as Northflank can keep execution in your account while reducing the Kubernetes and platform work your team operates directly. ### Can an own-cloud sandbox access private company APIs safely? Not on placement alone. Give each workload a narrow route, scoped identity, short-lived credentials, and API-level authorization. On Northflank BYOC, [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies) can restrict sandbox traffic to approved workloads, projects, IP addresses or CIDRs, FQDNs, or hostnames, while the target API still authorizes each action. ## Related articles about AI-agent sandboxes and BYOC - [Top BYOC AI sandboxes for running untrusted code in 2026](https://northflank.com/blog/top-byoc-ai-sandboxes) - [How to sandbox AI agents](https://northflank.com/blog/how-to-sandbox-ai-agents) - [How to deploy AI-built applications securely in your own cloud](https://northflank.com/blog/securely-deploy-ai-applications-in-your-cloud) - [Persistent vs ephemeral AI sandboxes](https://northflank.com/blog/persistent-vs-ephemeral-ai-sandboxes) - [How to isolate AI agents that have access to company data](https://northflank.com/blog/how-to-isolate-ai-agents-with-company-data)

Best runtime platforms for AI applications and production infrastructure

2026-08-20T16:45:00.000Z

## TL;DR: What are the best runtime platforms for AI applications? 1. **Northflank:** Best for running the full AI production stack, from GPU workloads and agent sandboxes to application deployment, databases, CI/CD, and infrastructure control. 2. **Modal:** Best for serverless GPU compute, inference, training, and AI workloads. 3. **E2B:** Best for running AI-generated and untrusted code in isolated sandboxes. 4. **Amazon Bedrock AgentCore:** Best for building and operating AI agents on AWS. 5. **Replicate:** Best for running open-source and custom models through managed APIs. 6. **Together AI:** Best for managed inference and open-source models. > **Northflank is a runtime platform for AI applications, combining [GPU workloads](https://northflank.com/product/gpu-paas), [isolated sandboxes](https://northflank.com/product/sandboxes), [application deployment](https://northflank.com/product/deployments), [preview environments](https://northflank.com/product/preview-environments), [databases](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), [CI/CD](https://northflank.com/docs/v1/application/release/ci-cd-on-northflank), and infrastructure control in one platform.** You can also deploy it in your own cloud with [BYOC](https://northflank.com/product/bring-your-own-cloud) when you need more control over your infrastructure and data. [Get started with Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > Running an AI application in production involves more than hosting a model. Depending on the workload, you may need GPU inference, isolated environments for AI-generated code, application hosting, databases, storage, CI/CD, secrets, access controls, and observability. The challenge is that most platforms specialize in one or two of these areas. This guide compares the best runtime platforms for AI applications in 2026, what each platform covers, and which workloads they are best suited for. ## What is an AI runtime platform? An AI runtime platform provides the infrastructure needed to run an AI application in production. Depending on the application, this can include model inference, agent execution, application hosting, databases, and deployment infrastructure. Some platforms focus on a specific part of the stack, such as GPU inference or isolated environments for AI agents, while others cover multiple layers from a single platform. The right choice depends on what your application needs to run reliably in production and which parts of the infrastructure you want the platform to manage. ## What AI applications need in production AI applications can look very different from traditional web applications, but most production systems eventually need several common infrastructure layers: - **Model inference:** Run models on CPUs or GPUs. Managed APIs handle this for you, while self-hosted models require GPU infrastructure and a serving framework. - **Agent and code execution:** Run AI-generated code, shell commands, browser sessions, and other tools in isolated environments. Stronger isolation, such as microVMs, can be useful for untrusted or AI-generated code. - **Application hosting:** Run APIs, frontends, background workers, scheduled jobs, webhooks, and other services that make up the application. - **Data and storage:** Store application state, embeddings, caches, files, datasets, and model artifacts using databases such as PostgreSQL, caches such as Redis, and object storage. - **Security and governance:** Manage access control, SSO, secrets, private networking, audit logs, and separate development, staging, and production environments. Regulated workloads may also require control over where infrastructure and data are hosted. ## Runtime platform comparison | Platform | GPU/model compute | Agent/code execution | Application hosting | Databases | Deployment model | Best for | | --- | --- | --- | --- | --- | --- | --- | | **Northflank** | Yes | Yes | Yes | Yes | Managed cloud, BYOC, and forward-deployed control plane | Full-stack production AI infrastructure | | **Modal** | Yes | Yes | Limited | No | Managed only | AI and ML compute | | **E2B** | No | Yes | No | No | Managed/self-hosted options | AI code execution | | **Amazon Bedrock AgentCore** | Not directly | Yes | Limited | Via AWS services | AWS | AWS-native agent orchestration and runtime | | **Replicate** | Yes | No | No | No | Managed only | Managed model inference | | **Together AI** | Yes | No | No | No | Managed only | Open-source model inference | ## Best runtime platforms for AI applications ### 1. Northflank [Northflank](https://northflank.com/) is a runtime platform for running applications and infrastructure, including AI workloads. It combines GPU compute, application deployment, isolated sandboxes, databases, CI/CD, and infrastructure management in a single platform. That makes it particularly useful when an AI application needs more than model inference alone. **What it covers** Northflank supports GPU workloads for AI inference and other GPU-intensive applications, alongside standard CPU workloads. It also provides microVM-backed sandboxes for running untrusted or AI-generated code. Sandboxes run in isolated environments with their own kernel and are designed for workloads such as AI agents, generated code, user-submitted code, and CI/CD jobs. The platform also provides application deployment, CI/CD, environments, networking, persistent storage, and managed databases. This allows the API, workers, inference services, sandboxes, and data infrastructure for an AI application to be managed from the same platform. Northflank also supports deploying sandboxes into your own cloud infrastructure through BYOC. **Why choose it** Northflank is a strong option when you need multiple parts of an AI production stack rather than a single specialized service. For example, an AI coding application could run its web application and API on Northflank, use GPU-backed services for inference, create isolated sandboxes for agent-generated code, and connect those workloads to persistent databases and storage. The same infrastructure can also be deployed in your own cloud environment when greater control over the infrastructure is required. **Limitations** If you only need managed model inference, a specialized inference platform may be a better fit. Northflank is designed for teams that need to run and manage the broader production environment around their AI application. **Best for** Northflank is best for teams building production AI applications that need a combination of GPU compute, agent execution, application hosting, data infrastructure, and infrastructure control. **Run AI applications on Northflank** Northflank supports GPU workloads, isolated AI sandboxes, application deployment, managed databases, CI/CD, and BYOC infrastructure. You can [get started with Northflank](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ### 2. Modal Modal is a serverless infrastructure platform for AI and compute-intensive workloads. It provides GPU compute, inference, training, batch workloads, and isolated sandboxes through a code-first interface. **What it covers** Modal supports GPUs including A100, H100, H200, B200, and B300, depending on availability. Its Sandbox product provides isolated environments for running arbitrary or AI-generated code, with support for GPUs and persistent storage. Modal also supports inference, training, fine-tuning, and batch workloads. **Why choose it** Modal is a strong choice for teams that want serverless GPU infrastructure through a code-first workflow. You can use the same platform for inference, training, batch jobs, and sandboxed execution. **Limitations** Modal is primarily focused on AI and compute infrastructure rather than broader application infrastructure. Teams that need managed databases, extensive application services, or infrastructure portability may need additional services. **Best for** Modal is best for ML engineers and AI teams that prioritize serverless GPU compute, inference, training, and sandboxed execution. ### 3. E2B E2B focuses on running AI-generated code in isolated environments. It provides the execution layer that AI agents use to run code, commands, and other tools. **What it covers** E2B provides sandbox environments where agents can execute code, inspect results, and destroy the environment when the task is complete. This makes it useful for coding agents, data analysis, code interpreters, and applications that execute user-generated code. **Why choose it** E2B is useful when you already have your application hosting and model infrastructure but need a dedicated, secure environment for code execution. **Limitations** E2B is not a complete application runtime. You still need separate infrastructure for your application, databases, model inference, and other services. **Best for** E2B is best for AI applications where isolated code execution is the primary infrastructure requirement. ### 4. Amazon Bedrock AgentCore Amazon Bedrock AgentCore provides a managed runtime for deploying and running AI agents and tools. It is framework-agnostic and supports frameworks such as LangGraph, Strands, and CrewAI. **What it covers** AgentCore handles infrastructure management, scaling, session management, and security isolation for agent workloads. It can also work with different model providers. **Why choose it** Its main advantage is integration with AWS. Teams already using AWS can build their agent runtime around AgentCore while keeping their wider infrastructure in the AWS ecosystem. **Limitations** AgentCore is primarily suited to AWS-centric teams. Organizations that need multi-cloud or infrastructure portability may prefer a platform that runs across different environments. **Best for** Amazon Bedrock AgentCore is best for organizations building AWS-native AI agents that want a managed agent runtime. ### 5. Replicate Replicate provides a managed API for running AI models without managing GPU infrastructure yourself. You can run published models or deploy your own custom models. **What it covers** Replicate provides access to models for image, video, language, and audio workloads, along with support for custom models and dedicated deployments. **Why choose it** Replicate removes much of the infrastructure work involved in model serving. Instead of provisioning GPUs and configuring a serving stack, you can call models through an API. **Limitations** Replicate primarily handles model execution. Your application, databases, authentication, background workers, and other infrastructure still need to run elsewhere. **Best for** Replicate is best for teams that want managed model inference without operating GPU infrastructure. ### 6. Together AI Together AI provides managed inference for open-source models through serverless models and dedicated endpoints. **What it covers** Together AI focuses on inference across a broad range of open-source models. Dedicated endpoints provide reserved infrastructure for workloads that need more predictable performance or consistent latency. **Why choose it** Together AI gives teams access to open models without requiring them to operate the underlying GPU infrastructure and serving stack. **Limitations** Together AI focuses primarily on inference rather than the complete application runtime. You still need separate infrastructure for your application, databases, agent execution, and other services. **Best for** Together AI is best for teams that want managed open-source model inference, particularly when model variety and dedicated endpoints are important. ## How to choose an AI runtime platform The right platform depends on how much infrastructure your AI application actually needs. | If you need... | Consider... | | --- | --- | | **A complete production platform** | **Northflank** | | **AI and ML compute** | **Modal, Northflank** | | **Secure code execution for AI agents** | **Northflank, E2B, Modal** | | **An AWS-native agent runtime** | **Amazon Bedrock AgentCore** | | **Managed model inference** | **Replicate, Together AI** | ## Conclusion AI applications are becoming more infrastructure-intensive. A production system may need model inference, GPU compute, isolated agent execution, application hosting, databases, storage, CI/CD, and security controls, and no single platform is necessarily the right choice for every layer. Specialized platforms can make sense when you need a specific capability, such as Replicate and Together AI for inference, E2B for isolated code execution, or Amazon Bedrock AgentCore for AWS-native agent workloads. For teams that need more of the production stack in one place, **Northflank provides a broader runtime environment for AI applications**, combining GPU workloads, isolated sandboxes, application deployment, databases, CI/CD, and infrastructure control. The best runtime platform ultimately depends on the infrastructure your application needs and how much complexity your team wants to manage. **Run your AI application on Northflank** Deploy GPU workloads, AI agents, application services, databases, and isolated sandboxes from one platform. [Get started with Northflank](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ## FAQ: best AI runtime platforms ### What is an AI runtime platform? An AI runtime platform provides the infrastructure needed to run AI applications in production, including compute, inference, agent execution, application hosting, data, and security. ### What is the difference between an AI runtime and an inference platform? An inference platform focuses on running models, while an AI runtime can cover the broader infrastructure needed to run the application around those models. ### Do AI applications need GPUs? Not always. You only need GPUs if you are running models yourself or performing GPU-intensive workloads such as inference or fine-tuning. ### Do AI agents need isolated sandboxes? If an agent executes AI-generated or user-provided code, isolated sandboxes can provide an additional security boundary and reduce the risk of that code affecting your application or infrastructure. ### Can I combine multiple AI runtime platforms? Yes. You can combine specialized platforms for inference, agent execution, and application hosting, although using multiple platforms increases integration and operational complexity. ### Should I self-host AI inference or use a managed API? Managed inference is simpler because the provider handles the infrastructure and scaling. Self-hosting gives you more control over costs, hardware, latency, and data residency. ### What is the best runtime platform for AI applications? There is no single best option. **Northflank** is a strong choice for teams that need application hosting, GPU workloads, agent sandboxes, databases, CI/CD, and infrastructure control in one platform, while platforms such as **Modal**, **E2B**, **Replicate**, and **Together AI** focus on specific parts of the AI runtime stack.

Which platform is best for running AI-generated code securely at scale?

2026-08-20T16:06:00.000Z

Generating code is easier. The harder question is where it runs when agents can install packages and open network connections at scale. Reviewed AI-built apps need a governed deployment path. An agent executing new code needs an AI agent sandbox platform. This article compares Northflank, E2B, Modal, and Cloudflare Sandbox SDK across isolation, lifecycle, concurrency, infrastructure placement, enterprise controls, and support for the surrounding production stack. ## TL;DR: Which platform is best for running AI-generated code securely at scale? The right platform depends on the isolation boundary, lifecycle, scale, infrastructure placement, and whether sandboxes must operate as part of a wider production stack. - **Northflank** fits teams that need to run AI-generated code securely at scale in sandboxes isolated with microVMs (Kata Containers with Cloud Hypervisor or Firecracker) or gVisor, alongside the surrounding application stack, including APIs, workers, jobs, databases, storage, and GPU workloads. - **E2B** fits teams that want a Firecracker sandbox API and plan to operate the surrounding application stack elsewhere. - **Modal** fits Python-first machine learning, evaluation, and reinforcement-learning workloads that need high managed concurrency. - **Cloudflare Sandbox SDK** fits agent control planes already running on Cloudflare Workers. If your team needs a platform for running AI-generated code securely at scale, [Northflank Sandboxes](https://northflank.com/product/sandboxes) provide microVM or gVisor isolation, ephemeral or persistent execution, GPU support, private networking, secrets, and platform access controls. Sandboxes run alongside APIs, workers, jobs, databases, and storage on the same platform. Northflank has operated millions of microVMs monthly since 2021. Sandboxes boot in under one second and have no platform-imposed session-duration limit; in the [ComputeSDK 2026 Scale Invitational](https://platform.computesdk.com/scale-invitational), Northflank reached 100,000 concurrent live sandboxes from a cold start in 24 seconds with zero failures. With Northflank, enterprises can apply SSO, RBAC, scoped API access, audit logs, and customer-cloud deployment. Teams of any size can start self-serve on [Northflank Cloud](https://northflank.com/cloud/northflank) or use [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud) to run sandboxes in their own cloud account, retaining the same workflow as the stack grows. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss isolation, concurrency, private networking, cloud placement, compliance, or migration requirements. ## What does running AI-generated code securely require? Running AI-generated code securely requires an execution boundary plus controls for network access, credentials, resources, retained state, and teardown. Evaluate these controls together: - **Tenant and isolation boundary:** Define which users or tasks may share an environment, then apply [sandbox isolation](https://northflank.com/blog/how-to-sandbox-ai-agents) to each trust boundary. The technology determines where it sits. [Standard containers](https://northflank.com/blog/what-is-container-isolation) share the host kernel. [gVisor](https://northflank.com/blog/what-is-gvisor) instead intercepts system calls through a user-space kernel, while [microVM runtimes](https://northflank.com/blog/what-is-a-microvm) give each workload a separate guest kernel. [Firecracker](https://northflank.com/blog/what-is-aws-firecracker) is a minimal VMM; [Kata Containers](https://northflank.com/blog/what-are-kata-containers) integrates VMMs such as [Cloud Hypervisor](https://northflank.com/blog/guide-to-cloud-hypervisor) with Kubernetes and OCI workflows. - **Network and credentials:** Isolation does not control which credentials code receives or which destinations it reaches. Scope both separately. For an internal API, provide a bounded path and authorize each action independently, as when you [connect an AI-built app to private APIs](https://northflank.com/blog/connect-ai-built-app-private-apis-corporate-network). - **Resource controls:** Limit CPU, memory, storage, processes, execution time, and creation rate so one workload cannot consume capacity reserved for other tenants. - **State and teardown:** Ephemeral sandboxes need reliable teardown. Persistent sandboxes also need expiry, storage quotas, reset and quarantine controls, and credential revocation. Enterprise teams should match these controls to the code's trust level, tenant model, data access, and impact. To test the path, [spin up a secure code sandbox and microVM with Northflank](https://northflank.com/blog/how-to-spin-up-a-secure-code-sandbox-and-microvm-in-seconds-with-northflank-firecracker-gvisor-kata-clh). ## How should you compare platforms for running AI-generated code securely at scale? Evaluate each AI code execution platform against the production workload and the controls your platform, security, and compliance teams require. | Requirement | Question to ask | Why it changes the decision | | --- | --- | --- | | Isolation | Does each trust boundary get a VM, microVM, user-space kernel, or ordinary container? | It determines the blast radius of a breakout or kernel attack. | | Network and credentials | Can you deny egress, allow only named destinations, and inject scoped secrets? | Most useful code needs access, but broad access defeats containment. | | Lifecycle | Can environments be ephemeral, persistent, paused, resumed, expired, and reliably deleted? | Coding agents and one-shot evaluators have very different state needs. | | Scale | What concurrency, creation rate, quota, and recovery behaviour can you prove with your workload? | A platform that works at ten sandboxes may queue or fail at ten thousand. | | Infrastructure placement | Can workloads run in your cloud, region, or on-premises environment when required? | Placement affects private routes, residency, procurement, and unit economics. | | Governance and audit | Does it support SSO, RBAC, scoped automation identities, audit logs, and containment? | Security teams need to approve access, investigate events, and revoke control. | | Surrounding stack | Can the platform also run APIs, workers, databases, jobs, GPUs, and observability? | At production scale, the sandbox is one component of a larger system. | Test image pulls, repository checkout, dependencies, readiness, and capacity queues at the burst shape you expect. ## How do platforms for running AI-generated code compare at a glance? The main differences are isolation, lifecycle, placement, and support for the surrounding stack. | Platform | Isolation | Lifecycle | Infrastructure placement | Strong fit | | --- | --- | --- | --- | --- | | Northflank | MicroVM options (Kata Containers and Firecracker) and gVisor, depending on workload and infrastructure | Ephemeral or persistent; persistent volumes survive scale to zero | Northflank Cloud, BYOC, or compatible BYOK clusters | Production AI stacks that need secure sandboxes, GPUs, application infrastructure, and enterprise controls together | | E2B | Firecracker microVMs | Timeouts, pause, and resume preserve filesystem and memory | Managed cloud or BYOC on AWS and Google Cloud | Linux sandbox execution through JavaScript/TypeScript or Python SDKs | | Modal | gVisor by default | Up to 24 hours; Volumes and filesystem snapshots retain selected state | Managed infrastructure | Python-first ML, evaluation, RL, and high managed concurrency | | Cloudflare Sandbox SDK | Separate VM per sandbox | Cloudflare Containers lifecycle; each sandbox container runs in its own VM | Cloudflare Workers and Containers | Workers-native agents that need isolated command and file execution | ## Which platforms can run AI-generated code securely at scale? The platform fit depends on whether you need a standalone API, managed concurrency, Workers integration, or a complete production stack. ### 1. Northflank When AI-generated code needs to run securely at scale as part of a production product, Northflank combines microVM- or gVisor-isolated sandboxes with the surrounding application infrastructure, self-serve workflows, and enterprise controls. Its main capabilities for this use case are: - **Isolation:** [Northflank sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) support hardware-virtualized microVM approaches such as Kata Containers and Firecracker, plus gVisor user-space-kernel isolation. The runtime depends on the workload and infrastructure; Northflank Cloud GPU workloads use gVisor by default. - **Execution interfaces:** Deploy OCI images and manage sandboxes through the Northflank dashboard, [REST API](https://northflank.com/docs/v1/api/use-the-api), [CLI](https://northflank.com/docs/v1/api/use-the-cli), or [JavaScript client](https://northflank.com/docs/v1/api/use-the-javascript-client). - **Lifecycle and storage:** Sandboxes have no platform-imposed session-duration limit. Use [ephemeral storage](https://northflank.com/docs/v1/application/scale/increase-storage) or attach a [persistent volume](https://northflank.com/docs/v1/application/databases-and-persistence/add-a-volume). [Scaling to zero](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) stops compute billing while the configuration and volume remain. - **Networking:** Expose [public or private ports](https://northflank.com/docs/v1/application/network/configure-ports). On [BYOC clusters](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements), [Network Policies](https://northflank.com/docs/v1/application/network/configure-network-policies) can restrict ingress and egress by workload, project, IP/CIDR, or FQDN. - **Full-stack infrastructure:** Run [services](https://northflank.com/docs/v1/application/run/run-an-image-continuously), [jobs](https://northflank.com/docs/v1/application/run/run-an-image-once-or-on-a-schedule), [databases](https://northflank.com/docs/v1/application/databases-and-persistence/deploy-a-database), storage, and GPU workloads around the sandbox on the same platform. - **Work from your AI coding tool:** If you use a compatible coding agent, install [Northflank Skills](https://github.com/northflank/skills) to give it Northflank-specific guidance for deploying, operating, and automating sandbox workloads and the surrounding application stack through the CLI or API. - **Security and governance:** Apply [secret injection](https://northflank.com/docs/v1/application/secure/inject-secrets), [scoped API roles](https://northflank.com/docs/v1/application/secure/grant-api-access), [SAML or OIDC SSO](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation), [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), and [platform audit logs](https://northflank.com/docs/v1/application/observe/audit-logs). - **Production scale:** [Northflank has operated millions of microVMs each month since 2021](https://northflank.com/product/sandboxes) across startups, public companies, and government deployments. In the [ComputeSDK 2026 Scale Invitational](https://platform.computesdk.com/scale-invitational), Northflank also reached 100,000 concurrent live sandboxes from a cold start in 24 seconds with zero failures. - **Pricing:** [Northflank Cloud bills per second](https://northflank.com/pricing) at $0.01667 per vCPU-hour and $0.00833 per GB-hour. With self-serve BYOC, you pay your cloud provider directly, retain your cloud credits and existing billing relationships, and Northflank charges $0.01389 per vCPU-hour, $0.00139 per GB-hour, and $0.00278 per GB of GPU VRAM per hour. For a provider-by-provider view, the [AI sandbox pricing comparison](https://northflank.com/blog/ai-sandbox-pricing) compares PaaS rates, billing models, GPU pricing, and BYOC costs at scale. - **Infrastructure placement:** Deploy on [Northflank Cloud](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-on-northflank), use [BYOC sandbox clusters](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-in-your-cloud) for workloads in your cloud account, or use [BYOK for a compatible Kubernetes cluster](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements). - **Compliance**: Northflank is [SOC 2 Type 2 compliant and HIPAA compliant](https://northflank.com/security), with BAAs supported under Enterprise contracts. Platform compliance does not make your application compliant. Northflank fits teams wanting one operating model for isolated execution and the surrounding application, from self-serve development to enterprise governance. [Versaia runs its full AI agent orchestration stack on Northflank](https://northflank.com/blog/versaia-runs-agent-orchestration-platform-on-northflank) for enterprise, healthcare, and public-sector customers. After migrating from AWS in under two weeks, it reported 60% lower compute costs and voice throughput increasing from 4–5 to 15 concurrent calls per node. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss isolation, concurrency, private networking, cloud placement, compliance, or migration requirements. ### 2. E2B E2B provides Firecracker Linux sandboxes with JavaScript/TypeScript and Python SDKs and authenticated controller access. Its main capabilities for this use case are: - **Isolation and access:** Firecracker microVMs with authenticated access to the sandbox controller. - **Developer interface:** JavaScript/TypeScript and Python SDKs designed around command and file execution. - **Lifecycle:** Pause and resume preserve filesystem and memory, including running processes. Continuous runtime is up to 24 hours on Pro and one hour on Base. - **Scale and placement:** Hobby supports 20 concurrent sandboxes, Pro supports 100 with add-ons up to 1,100, and Enterprise supports 1,100+ with custom creation rates. E2B's managed BYOC option is available only to Enterprise customers and currently supports AWS and Google Cloud. E2B fits when you need a sandbox API and operate the wider stack elsewhere. For BYOC, review its control-plane and metrics boundary. ### 3. Modal Modal offers gVisor sandboxes and Volumes for Python-first ML, evaluation, and RL workloads. Its main capabilities for this use case are: - **Isolation:** gVisor by default. - **Developer interface:** Python is the primary SDK. JavaScript/TypeScript and Go SDKs are Beta. - **State and compute:** Sandboxes run for up to 24 hours. Volumes and filesystem snapshots retain selected state, while Modal's wider platform supports GPU-heavy ML workloads. - **Networking:** Sandboxes cannot accept inbound connections or access other Modal workspace resources by default. Public egress remains available unless you block it or configure CIDR or domain allowlists. - **Scale:** Modal supports up to 50,000 concurrent sandboxes per customer. Modal fits when managed concurrency and ML integration outweigh customer-cloud placement. ### 4. Cloudflare Sandbox SDK Cloudflare Sandbox SDK keeps Workers-based orchestration and isolated execution in the same ecosystem. Its main capabilities for this use case are: - **Isolation:** A separate VM per sandbox, with filesystem, process, network, and resource boundaries. - **Developer interface:** Command execution, files, background processes, and service exposure from Workers applications. - **Platform integration:** Lifecycle, placement, routing, and limits inherit Cloudflare Containers and Workers behaviour. - **Transport:** With the stable SDK's default HTTP transport, each operation consumes a Workers subrequest; RPC multiplexes operations over one connection. The 1.0 preview uses RPC exclusively. - **Availability:** Workers Paid is required. The current package remains stable, while version 1.0 is in preview and recommended for new projects. Cloudflare Sandbox SDK fits Workers-native systems. You still own application-level security. ## Which platform should you choose for running AI-generated code securely at scale? Match the platform abstraction to the system you are building. - **Northflank** fits teams that need secure sandbox execution as part of a production AI stack, with persistent or ephemeral environments, GPUs, APIs, workers, jobs, databases, storage, enterprise identity, and managed-cloud or customer-cloud deployment under one operating model. It remains self-serve for teams of any size. - **E2B** fits teams that need short-lived or resumable Linux sandboxes through a standalone Firecracker API while operating the surrounding application stack elsewhere. - **Modal** fits Python-first evaluation, machine learning, and reinforcement-learning fleets that need high managed concurrency. - **Cloudflare Sandbox SDK** fits teams whose agent control plane already runs on Cloudflare Workers and benefits from Workers-native integration. If concurrency is your main constraint, use the [high-concurrency sandbox platform comparison](https://northflank.com/blog/best-platforms-for-high-concurrency-sandbox-environments) and test your own creation curve. If cost drives the decision, model the full workload with the [AI sandbox pricing comparison](https://northflank.com/blog/ai-sandbox-pricing). ## Frequently asked questions about running AI-generated code securely at scale These answers clarify common platform decisions. ### Does every AI-built application need a sandbox? Not necessarily. A reviewed, fixed artifact can use the same risk-based controls as comparable human-written software. Strong isolation becomes important when it executes generated code, user submissions, unknown packages, files, or commands. Northflank runs conventional services and isolated sandboxes on one platform, so the runtime can match the workload. See [how to build an enterprise platform for AI-generated applications](https://northflank.com/blog/build-enterprise-ai-application-platform). ### Is a microVM enough to make AI-generated code safe? No. You still need scoped credentials, egress rules, resource limits, validation, authorization, timeouts, monitoring, and teardown. On Northflank, combine isolation with secret injection, private ports, and scoped API roles; BYOC clusters can also apply Network Policies. For sensitive access, see [how to isolate AI agents with company data](https://northflank.com/blog/how-to-isolate-ai-agents-with-company-data). ### Should you use managed sandboxes or BYOC? It depends on your network, residency, procurement, and cost requirements. Managed sandboxes reduce infrastructure work; BYOC supports existing private routes or customer-controlled infrastructure. With Northflank, teams can deploy on [Northflank Cloud](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-on-northflank) or through [self-serve BYOC](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-in-your-cloud) while retaining the same platform workflow. Assess logs, builds, images, backups, secrets, and control-plane metadata separately. ### How do you test a sandbox platform before production? Test normal, denied, degraded, and burst conditions using your real images and workload shape. Measure startup time, sustained concurrency, tail latency, failure rate, teardown, and recovery. Attempt forbidden network access, revoke credentials during execution, exhaust resource limits, and check for orphaned environments. For large fleets, see [how to run millions of concurrent AI sandboxes](https://northflank.com/blog/how-to-run-millions-concurrent-ai-sandboxes). ## Related articles about secure AI code execution - [Best platforms for high-concurrency sandbox environments](https://northflank.com/blog/best-platforms-for-high-concurrency-sandbox-environments) - [How to run millions of concurrent AI sandboxes](https://northflank.com/blog/how-to-run-millions-concurrent-ai-sandboxes) - [Persistent vs ephemeral AI sandboxes](https://northflank.com/blog/persistent-vs-ephemeral-ai-sandboxes) - [AI sandbox pricing comparison](https://northflank.com/blog/ai-sandbox-pricing) - [How to isolate AI agents that have access to company data](https://northflank.com/blog/how-to-isolate-ai-agents-with-company-data)

What is sovereign AI? An enterprise infrastructure guide

2026-08-19T16:20:00.000Z

Your AI pilot works until production review asks three questions: where will the model and its data run, who can access them, and who can change or stop the system? If the answers depend entirely on a vendor’s cloud account, network, administrators, or release schedule, your enterprise has limited control over the boundary around that AI workload. Sovereign AI defines that boundary. This article explains when you need it, which deployment models fit, and how to run AI on infrastructure your enterprise controls. ## TL;DR: What is sovereign AI? How enterprises can run AI on infrastructure they control Sovereign AI is the ability to run and govern AI within infrastructure, data, model, operational, and jurisdictional boundaries your organisation chooses. - Start with a specific requirement, such as keeping inference data in your cloud account, operating in an approved region, using reserved GPUs, or running without an external control-plane dependency. - Treat sovereignty as a spectrum. A managed regional service, BYOC, an existing Kubernetes cluster, and an on-premises control plane offer different boundaries. - Control the complete workload, including inference, application services, databases, vector stores, secrets, network traffic, logs, backups, and deployment artifacts. - Verify what remains under vendor control. BYOC or open-weight models can support sovereignty, but neither makes the whole AI system sovereign on its own. - Test whether you can revoke access, stop workloads, block egress, restore state, move artifacts, and keep operating during a provider or network failure. If your enterprise needs AI workloads to run on infrastructure it controls, [Northflank](https://northflank.com/) deploys models, GPU services, applications, jobs, databases, and sandboxes on [Northflank’s managed cloud](https://northflank.com/features/managed-cloud) or [your own infrastructure](https://northflank.com/features/bring-your-own-cloud). Use self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud) for a Northflank-managed data plane in your cloud account, or [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements) to connect an existing Kubernetes cluster on your own infrastructure. For a stricter boundary, Northflank Enterprise offers a [forward-deployed control plane](https://northflank.com/docs/v1/application/enterprise#forward-deployed-control-plane) by arrangement, so platform operations, scheduling, and API traffic can remain inside your network. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## What is sovereign AI? Sovereign AI is an approach to building, operating, and governing AI systems within boundaries your enterprise can define and enforce. There is no universally accepted definition or certification, so your enterprise needs to translate sovereign AI into controls its security, legal, risk, and platform teams can test. To determine whether an AI architecture meets those boundaries, assess these three connected areas below: ### Infrastructure control Infrastructure control determines whose cloud account, VPC, cluster, hardware, and network run the AI workload. It also covers GPU capacity, traffic paths, and administration of the underlying resources. Running an inference server in your AWS account gives you more infrastructure control than calling a shared external endpoint. It does not, by itself, tell you where the management plane stores metadata or whether a vendor can administer the cluster. ### Data and model control Data and model control determines where prompts, outputs, documents, embeddings, training data, model weights, images, logs, and backups travel and persist. Open-weight models can improve portability and let you host inference yourself. Using an open-weight model does not, by itself, set network policies, protect credentials, restrict administrator access, or control where application telemetry goes. Model choice is one part of the boundary. ### Operational and jurisdictional control Operational control determines who can deploy, update, observe, stop, and recover the system. You need named identities, least-privilege roles, workload credentials, audit records, controlled releases, and incident procedures. Jurisdictional control asks which entities operate the service and which laws apply. A chosen region supports residency, but [enforcing data residency for AI-built applications](https://northflank.com/blog/enforce-data-residency-ai-built-applications) also requires tracing logs, backups, builds, model downloads, and support paths. ## When does your enterprise need sovereign AI? You need sovereign AI controls when losing authority over an AI workload’s location, access, operation, or portability would create an unacceptable business, security, or regulatory risk. That requirement usually appears in concrete use cases: - A healthcare or financial application runs inference over regulated or contractually restricted data. - A retrieval-augmented generation system indexes internal documents that cannot leave approved regions or accounts. - An AI agent calls internal systems of record. The agent needs a bounded route, workload identity, and API permissions, not broad network access. The same design problem appears when you [connect an AI-built app to private APIs inside a corporate network](https://northflank.com/blog/connect-ai-built-app-private-apis-corporate-network). - A team fine-tunes a model using proprietary datasets, or your enterprise has reserved GPU capacity or committed cloud spend. - A defence, public-sector, or critical-infrastructure workload must run with restricted or no outbound dependency. Not every chatbot needs the strictest architecture. If an approved managed service meets your requirements, forcing it on-premises may add cost without reducing relevant risk. Define the requirement first. ## Which sovereign AI deployment model should your enterprise use? The right deployment model is the least operationally heavy option that satisfies your stated sovereignty requirements. | Deployment model | What you control | Best fit | Main question to verify | | --- | --- | --- | --- | | Managed regional cloud | Application configuration and an approved provider region | Workloads that need residency and enterprise controls without infrastructure ownership | Which data, metadata, operators, and dependencies can leave the region? | | BYOC | Cloud account, VPC, data-plane resources, network controls, and underlying bill | Teams that need workloads in their cloud account while a platform manages orchestration | Where does the control plane run, and what can it access? | | BYOK or on-premises | Existing Kubernetes cluster, hardware placement, and cluster network | Enterprises with established clusters, private cloud, or owned hardware | Which cluster lifecycle and platform responsibilities remain yours? | | Forward-deployed control plane | Data plane and platform control plane inside your environment | Air-gapped or tightly regulated workloads that cannot depend on an external control plane | How are updates, support, disaster recovery, and break-glass access handled? | BYOC is often the practical middle ground. The data plane runs in your cloud account while the vendor manages the developer experience and orchestration layer. Map both planes precisely: ask whether user traffic passes through the vendor, which metadata leaves your account, and what support personnel can access. Our guide to [what BYOC means in cloud computing](https://northflank.com/blog/what-is-byoc-in-cloud-computing) goes deeper into that architecture. If GPU availability or regional rules spread workloads across providers, use one governance layer. A consistent approach to [multi-cloud orchestration for AI workloads](https://northflank.com/blog/multi-cloud-orchestration-for-ai-workloads) avoids separate deployment and access processes for each cloud. ## How do you build a sovereign AI platform without creating another infrastructure silo? Build sovereignty into the same delivery path your teams use for ordinary production software, then add controls where AI changes the workload or risk. ### 1. Define the sovereignty boundary Inventory the model server, application, agent runtime, databases, vector stores, queues, secrets, registry, build pipeline, logs, backups, and external tools. For each component, state the allowed account, region, operator, network path, retention policy, and failure behaviour. For example, saying an AI workload “runs in Europe” is not enough if its prompts are sent to a global logging service. If your team needs to turn that approved boundary into repeatable infrastructure, Northflank [infrastructure-as-code templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code) can define services, databases, pipelines, integrations, and regional configuration instead of leaving the boundary in a checklist. ### 2. Keep the complete workload inside the intended data plane Place the inference service and the systems that feed it within the approved boundary. If an internal assistant retrieves documents from a vector database and writes outcomes to PostgreSQL, moving only the model server into your VPC leaves most of the sensitive path unresolved. Your platform should run GPU and CPU services, jobs, databases, volumes, and internal networking together. On Northflank, you can [deploy GPU workloads in your own cloud](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud) alongside [services](https://northflank.com/docs/v1/application/run/run-an-image-continuously), [jobs](https://northflank.com/docs/v1/application/run/run-an-image-once-or-on-a-schedule), [stateful workloads](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), and [private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank#private-networking). If your team also needs to coordinate training, inference, agents, sandboxes, and application delivery, see how to [manage enterprise AI infrastructure](https://northflank.com/blog/how-to-manage-enterprise-ai-infrastructure) beyond GPU provisioning. ### 3. Control identities, secrets, and network paths Use your identity provider for human access, granular roles for platform actions, and workload identities or short-lived credentials for service-to-service access. On Northflank, you can connect [SAML or OIDC SSO](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation#configure-single-sign-on-sso), apply [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), configure [workload identities](https://northflank.com/docs/v1/application/bring-your-own-cloud/configure-workload-identity), and [inject secrets](https://northflank.com/docs/v1/application/secure/inject-secrets) only into the workloads that need them. Private placement does not make every connection safe. Use Northflank [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies) to restrict ingress and egress, keep internal services on [private ports](https://northflank.com/docs/v1/application/network/configure-ports#private-ports), and authorise API actions independently of network location. Apply the same boundaries when [connecting AI-built apps to company data securely](https://northflank.com/blog/connect-vibe-coded-apps-company-data-securely). ### 4. Make models and deployment artifacts portable Package inference servers and applications as reproducible container images. Pin model versions, record their source and licence, and keep approved artifacts in controlled registries. Northflank [templates and GitOps](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code#manage-infrastructure-with-gitops) let you version the application definition and reuse it with different configuration across approved regions or infrastructure. Portability gives you a tested exit path if pricing, availability, contracts, or jurisdictional requirements change. ### 5. Keep usable audit and operational evidence Record who changed configuration, deployed a model, modified a secret, or altered network policy. Northflank [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) provide evidence for platform events, while [log sinks](https://northflank.com/docs/v1/application/observe/configure-log-sinks) can send workload logs to an approved destination. Keep both distinct from application and model telemetry. Log prompts and outputs only when policy permits. Decide which events leave the environment, how long they are retained, and who can query them. ### 6. Test exit, containment, and recovery Your operational control is incomplete if operators cannot revoke credentials, stop inference, block egress, quarantine state, restore data, and redeploy approved artifacts during an incident. Test provider exit too: export the application definition and state, then rebuild them in another approved location. Northflank supports [database backup and restore](https://northflank.com/docs/v1/application/databases-and-persistence/backup-restore-and-import-data), while [versioned infrastructure-as-code templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code#versioning-and-history-for-templates) give your team a repeatable application definition for recovery or redeployment. ## How does Northflank help enterprises run sovereign AI infrastructure? Northflank is a full-stack application platform that helps your enterprise run and govern AI models, applications, data services, and supporting infrastructure within a deployment boundary your enterprise controls. - **Choose the infrastructure boundary:** Use [Northflank’s managed cloud](https://northflank.com/features/managed-cloud), self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud) for a cluster provisioned in your cloud account, or [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements) to import an existing Kubernetes cluster. - **Run the whole AI application:** Deploy [GPU workloads in your own cloud](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud) alongside CPU services, jobs, databases, volumes, and private services. - **Apply enterprise identity and governance:** Use [SAML or OIDC SSO and directory sync](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation), MFA, [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [scoped API roles](https://northflank.com/docs/v1/application/secure/grant-api-access), and [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs). - **Restrict data paths and credentials:** Use [workload identities](https://northflank.com/docs/v1/application/bring-your-own-cloud/configure-workload-identity), [secret injection](https://northflank.com/docs/v1/application/secure/inject-secrets), [private ports](https://northflank.com/docs/v1/application/network/configure-ports#private-ports), and [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies) to narrow what each workload can access. - **Control releases and evidence:** Use [pipelines](https://northflank.com/docs/v1/application/release/configure-workflows) and [preview environments](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) to validate changes before production, then send platform logs to approved destinations with [log sinks](https://northflank.com/docs/v1/application/observe/configure-log-sinks). - **Operate infrastructure from your AI coding tools:** Install [Northflank Skills](https://github.com/northflank/skills) so compatible coding agents can deploy services, manage databases, and configure environments through the [Northflank CLI](https://northflank.com/docs/v1/api/use-the-cli) and [API](https://northflank.com/docs/v1/api/use-the-api) while workloads continue to run inside your chosen infrastructure boundary. - **Keep the control plane inside your boundary when required:** A [forward-deployed control plane](https://northflank.com/docs/v1/application/enterprise#forward-deployed-control-plane) is available to qualifying Enterprise customers by arrangement for environments that cannot depend on Northflank’s managed control plane. Northflank is [SOC 2 Type 2 compliant and HIPAA compliant](https://northflank.com/security), with BAAs supported under Enterprise contracts. Your architecture, data handling, model use, and procedures remain part of the compliance assessment. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss workload placement, GPU infrastructure, network boundaries, control-plane requirements, and migration. ## What should you ask a sovereign AI platform vendor? Turn “sovereign” into an architecture and operating agreement you can inspect. - Which resources run in our account, and which remain in yours? - Does workload traffic pass through your control plane? - What metadata, logs, builds, images, backups, and support data leave our environment? - Who can access the platform or workload, under what approval, and with what audit record? - Can workloads use our identities, keys, registries, DNS, observability tools, and private networks? - Can we restrict egress and keep operating without the vendor control plane or internet? - Who controls platform and model updates? - Can we export application definitions, artifacts, logs, and state in usable formats? - Which residency, deletion, incident, and subcontractor commitments appear in the contract? The answer need not be “everything stays here.” It must match your approved boundary, with exceptions visible before production. ## Frequently asked questions about sovereign AI These answers clarify where sovereign AI overlaps with common infrastructure and model terms. ### Is sovereign AI the same as private AI? Not exactly. Private AI emphasises data protection and access. Sovereign AI also covers infrastructure, models, operational authority, portability, and jurisdiction. ### Does sovereign AI require on-premises infrastructure? No. An approved managed region, BYOC, an existing Kubernetes cluster, or on-premises infrastructure may satisfy your boundary. On-premises becomes relevant for hardware ownership, disconnected operation, or stricter jurisdictional control. ### Is BYOC enough to make AI sovereign? Not on its own. You must still assess the vendor control plane, metadata, administrator access, artifact paths, logging, backups, model dependencies, and jurisdiction. ### Do you need open-source or open-weight models for sovereign AI? It depends. Open-weight models support self-hosted inference and portability, but you still need controlled infrastructure, data paths, identity, operations, and licensing. A proprietary model can fit a less strict boundary if its deployment and contractual controls meet your requirements. ## Related articles about sovereign AI infrastructure Use these guides to work through the individual architecture decisions behind sovereign AI. - [What is BYOC in cloud computing?](https://northflank.com/blog/what-is-byoc-in-cloud-computing): Understand the control-plane and data-plane split before placing workloads in your cloud account. - [How to deploy AI-built applications securely in your own cloud](https://northflank.com/blog/securely-deploy-ai-applications-in-your-cloud): Build the identity, network, release, and audit controls around AI-generated applications. - [How do you enforce data residency for AI-built applications?](https://northflank.com/blog/enforce-data-residency-ai-built-applications): Trace data through runtime, storage, logs, backups, and external services. - [How to manage enterprise AI infrastructure](https://northflank.com/blog/how-to-manage-enterprise-ai-infrastructure): Operate training, inference, agents, sandboxes, and AI applications as one governed estate. - [Multi-cloud orchestration for AI workloads](https://northflank.com/blog/multi-cloud-orchestration-for-ai-workloads): Apply consistent controls when GPU capacity and residency requirements span providers.

How enterprises should separate development and production for vibe-coded apps

2026-08-19T16:19:00.000Z

A vibe-coded app can become a deployment in an afternoon. Risk appears when development uses the same customer database, credentials, or network access as the version employees depend on. Development and production need separate security boundaries, not two branch names pointing at the same infrastructure. This article explains how to separate state, secrets, access, networking, releases, and evidence without slowing delivery. ## TL;DR: How enterprises should separate development and production environments for vibe-coded apps Treat development and production as separate trust zones, with independent resources, state, credentials, permissions, network access, and release workflows. - Use local or shared development, an ephemeral preview for each pull request, persistent staging, and production as a practical default. Adapt the number of stages to the app's risk. - Never give non-production unrestricted access to production databases, queues, writable storage, or production credentials. - Build once and, where practical, promote the same immutable artifact, typically by container image digest. Supply environment-specific configuration and secrets when you deploy it. - Give builders self-service access to previews and non-production while reserving production credentials and release actions for narrower roles. - Test migrations, denied access, credential revocation, recovery, and rollback before a release reaches users. If your enterprise needs a controlled path for vibe-coded apps, [Northflank](https://northflank.com/) lets your platform team organize development, staging, and production with [Environments](https://northflank.com/docs/v1/application/release/set-up-environments), create isolated full-stack deployments for pull requests with [Preview Blueprints](https://northflank.com/docs/v1/application/release/manage-preview-blueprints), and automate releases with [Workflows](https://northflank.com/docs/v1/application/release/configure-workflows). Your builders can work quickly in non-production while [secret groups](https://northflank.com/docs/v1/application/secure/manage-secret-groups) and [project-restricted RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control) keep production credentials and infrastructure changes with the right people. Run the application on [Northflank Cloud](https://northflank.com/cloud/northflank), or use self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud) when production needs to run in your cloud account and use its existing network controls. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## What does environment separation mean for vibe-coded apps? Effective separation means development has no uncontrolled ability to read production data, use its credentials, change its resources, or bypass its release path. Use this four-stage model as a practical framework, not a fixed standard. A low-risk app may combine development and staging; a regulated app may need more environments. | Environment | Purpose | Data and integrations | Access | Lifetime or trigger | | --- | --- | --- | --- | --- | | Development | Fast iteration by a builder or team | Synthetic data and sandbox integrations | Broad builder access | Persistent or local | | Pull request preview | Validate one proposed change in isolation | Seeded test data and restricted integrations | Author and reviewers | Created for a PR, then deleted | | Staging | Test the combined release and operational process | Production-like shape without unrestricted production data | Engineering, QA, and approved reviewers | Persistent; updated after merge | | Production | Serve employees or customers | Live data and production integrations | Narrow operator and release roles | Updated only through the release workflow | The boundary matters more than the label. If `staging` can write to production with its API key, you still have one trust zone. If your team needs one release view, [Northflank Environments](https://northflank.com/docs/v1/application/release/set-up-environments) organize stages, resources, and workflows. Enforce isolation with separate resources or [projects](https://northflank.com/docs/v1/application/network/enable-multi-project-networking), [scoped secrets](https://northflank.com/docs/v1/application/secure/manage-secret-groups), [access roles](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), and [network controls](https://northflank.com/docs/v1/application/network/configure-network-policies). Environment isolation is one part of [secure enterprise vibe-coding deployment](https://northflank.com/blog/enterprise-vibe-coding-how-to-deploy-ai-generated-apps-safely). You still need application authentication, scoped permissions, safe runtime code execution, and security visibility. ## Which parts of a vibe-coded app must be separated? Separate every capability that could turn a development mistake into a production event. A different URL is not enough. ### 1. Application resources and state Each stage should have its own services and mutable state, including databases, queues, caches, object stores, search indexes, and writable volumes. This stops a generated cleanup script from deleting live records or test messages from reaching production workers. It also makes previews safe to destroy. Use synthetic or seeded data by default. If a test needs production-shaped data, minimize and mask it through an approved process. See [how to connect vibe-coded apps to company data securely](https://northflank.com/blog/connect-vibe-coded-apps-company-data-securely) for credential, user, and record-level controls. If each pull request needs a full-stack deployment, a Northflank [Preview Blueprint](https://northflank.com/docs/v1/application/release/manage-preview-blueprints) creates isolated services, databases, jobs, volumes, and secret groups. It updates with commits and can clean up when the request closes or merges. ### 2. Secrets and external integrations Give every environment credentials that work only there. Development passwords should not authenticate to production, test payment keys should not create live charges, and preview webhooks should not update customers. To keep environment-specific values out of the repository, use Northflank [secret groups](https://northflank.com/docs/v1/application/secure/manage-secret-groups) to inject build or runtime values into selected resources. Separate [RBAC permissions](https://northflank.com/docs/v1/application/secure/use-role-based-access-control) distinguish configuration groups from secret-value groups. Apply the boundary to internal services. A preview should use a mock, test endpoint, or scoped non-production route. When private integration is unavoidable, use the controls in [connecting an AI-built app to private corporate APIs](https://northflank.com/blog/connect-ai-built-app-private-apis-corporate-network). ### 3. Human and machine access Let builders create previews, view non-sensitive logs, and deploy to development without revealing production secrets or changing production infrastructure. Grant production access separately. Apply the same rule to machine identities. An AI coding agent that creates previews does not need production database permissions. Scope and revoke its token independently. If builders need self-service without production authority, use Northflank [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control) to control platform permissions. Roles can be restricted to projects, and API tokens inherit their permissions. A governed production project creates a harder boundary. ### 4. Network paths and public endpoints Give environments different domains and control ingress and egress. Development may need package registries and test APIs; production may need a private company route. Do not copy every route and allowlist between them. Use controls such as project boundaries, private ports, ingress restrictions, and BYOC network policies. Prevent previews from calling production-only hosts and authenticate public preview URLs. If production needs a separate network boundary, [Northflank projects are self-contained networks by default](https://northflank.com/docs/v1/application/network/enable-multi-project-networking). Cross-project private ingress is deliberate and works only within the same team and cluster. ### 5. Logs, alerts, and audit evidence Tag logs, metrics, traces, and alerts by environment and separate their destinations and response policies. Preview errors should not page production on-call; production security events should not disappear into development noise. If your security team needs evidence of infrastructure changes and releases, Northflank [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) include the triggering user, source, timestamp, and parent events. Keep them distinct from application logs and traces. ## What release path should a vibe-coded app follow? Every change should follow a controlled path through validation stages appropriate to its risk. Avoid rebuilding between validation and production when you can promote the tested artifact, and do not edit the live service after testing. 1. **Build and check the commit.** Run dependency, secret, static-analysis, and automated test checks that fit the app's risk. Produce a versioned container image. 2. **Create an isolated preview.** Deploy the proposed change with non-production secrets and state so reviewers can test the actual service, not only a screenshot from the coding tool. 3. **Validate the combined release in staging.** After merge, test how changes work together, including authentication, integrations, migrations, monitoring, and failure behavior. 4. **Promote the same immutable artifact where practical.** Use a container image digest rather than a mutable tag, then change environment-specific configuration at deployment. Require approval when the release's delegated authority or impact warrants it. 5. **Observe and contain.** Watch health, error, security, and business signals. Be ready to stop the deployment, revoke credentials, block another release, and restore a known-good version. If every change needs the same governed release path, Northflank [Workflows](https://northflank.com/docs/v1/application/release/configure-workflows) connect builds, deployments, jobs, backups, conditions, and approvals. GitOps can provide version history and support code review. Reuse build outputs where appropriate so later stages do not produce a different artifact. For the hands-on implementation, see [how to set up CI/CD for a vibe-coded app](https://northflank.com/blog/how-to-set-up-ci-cd-for-a-vibe-coded-app). If pull requests are the immediate gap, [ephemeral preview environments for vibe-coded apps](https://northflank.com/blog/ephemeral-preview-environments-vibe-coded-apps) goes deeper into per-change testing and cleanup. ## How should you handle databases and migrations for vibe-coded apps? Keep each environment's database separate and promote schema changes through the release path. Do not promote development data into production as part of a deployment. Test migrations against representative non-production data and prefer backward-compatible schema changes. When a migration must precede new code, back up production, run the migration as a job, verify it, and deploy only after success. For a zero-downtime expand-and-contract change, roll out the application and schema in multiple compatible steps; Northflank also supports running a backward-compatible migration after deployment. If your release changes the schema, Northflank's [migration workflow guidance](https://northflank.com/docs/v1/application/release/run-migrations) shows how to combine backup, job, condition, and deployment steps. It also recommends testing migrations in previews and checking rollback procedures. Treat application rollback and data rollback as different operations. Redeploying the previous image does not undo a destructive schema change. Test restore time, ownership, and compatibility before you need them during an incident. ## How much environment separation does each enterprise vibe-coded app need? The boundaries remain the same, but the number of stages and depth of review should follow the app's data, reach, and impact. A low-risk utility might move from a pull request preview directly to production. It still needs separate credentials, state, and access. An app using company records or private APIs usually needs staging, test integrations, denied-action and credential-revocation tests, and reviewed releases. A regulated app may also need performance tests, separation of duties, recovery exercises, and approved placement. For higher-risk production, use separate projects, clusters, or cloud accounts when compliance or blast radius requires them. An [internal vibe-coding platform](https://northflank.com/blog/how-to-build-an-internal-vibe-coding-platform) can provide approved patterns instead of making every builder design a release and security model. ## How does Northflank enforce environment separation for vibe-coded apps? Northflank Environments organize release stages; the security boundary comes from how you separate projects, resources, identities, secrets, and network paths. - **Separate every stage:** Use [Environments](https://northflank.com/docs/v1/application/release/set-up-environments) to organize resources and workflows for development, staging, and production. - **Test each change away from shared environments:** Use [Preview Blueprints](https://northflank.com/docs/v1/application/release/manage-preview-blueprints) to give each branch or pull request isolated full-stack resources and a unique URL, with automatic cleanup. - **Control every release:** Use [Workflows](https://northflank.com/docs/v1/application/release/configure-workflows) to connect builds, deployments, backups, migrations, conditions, and proportionate approvals in visual or JSON configuration. - **Keep credentials specific to their environment:** Use [secret groups](https://northflank.com/docs/v1/application/secure/manage-secret-groups) to inject build and runtime values only into required resources. - **Connect access to your enterprise identity policies:** Use [SAML or OIDC SSO, directory sync, and MFA enforcement](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation) to authenticate users and assign roles. - **Let builders work without giving them production authority:** Use [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control) to restrict projects and actions, and granular [API roles](https://northflank.com/docs/v1/application/secure/grant-api-access) to limit automation identities. - **Stop non-production workloads from reaching production:** Keep workloads in self-contained projects, then use BYOC [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies) to restrict ingress and egress. - **Show who changed what:** Use [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) to trace platform events to the identities that triggered them, keeping application activity in separate logs and traces. - **Run production where your requirements demand:** Start on [Northflank Cloud](https://northflank.com/cloud/northflank), or use [BYOC](https://northflank.com/features/bring-your-own-cloud) when the app must run in your cloud account with its network controls. - **Address security and procurement requirements:** Northflank is [SOC 2 Type 2 compliant and HIPAA compliant](https://northflank.com/security), with BAAs supported under Enterprise contracts. - **Keep AI-agent deployments on the governed path:** Give compatible agents [Northflank Skills](https://github.com/northflank/skills) for guidance on deploying and operating workloads through the API and CLI. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss environment architecture, release controls, data boundaries, access, and migration requirements. ## Frequently asked questions about separating development and production for vibe-coded apps Common questions include: ### Do all vibe-coded apps need staging? Not always. A low-risk app may use pull request previews for validation. It still needs production resources, data, secrets, and permissions separate from development. Add staging for combined releases, long-lived integrations, migrations, or production-like operations. ### Can staging use a copy of production data? Only through an approved process. Minimize and mask it, restrict access, record its origin, and protect remaining sensitive information. Prefer synthetic data. ### Should you rebuild the app for production? Prefer promoting the same immutable artifact by container image digest. Inject production configuration and secrets at deployment time so production runs what passed staging. ### Can the AI coding agent deploy directly to production? It depends on its authority. An agent-triggered release should pass the same tests, policy checks, proportionate approvals, and audit trail as a human release. The safer default is for the agent to create a pull request or preview while a separate identity controls production. ## Related articles about enterprise vibe-coded app deployment Related guides include: - [How to set up CI/CD for a vibe-coded app](https://northflank.com/blog/how-to-set-up-ci-cd-for-a-vibe-coded-app) - [Using ephemeral preview environments to test your vibe coded apps](https://northflank.com/blog/ephemeral-preview-environments-vibe-coded-apps) - [Enterprise vibe coding: how to deploy AI-generated apps safely](https://northflank.com/blog/enterprise-vibe-coding-how-to-deploy-ai-generated-apps-safely) - [How to build an internal vibe coding platform for your company](https://northflank.com/blog/how-to-build-an-internal-vibe-coding-platform) - [How to deploy vibe-coded apps to production](https://northflank.com/blog/how-to-deploy-vibe-coded-apps)

How to self-host GitLab

2026-08-19T15:00:00.000Z

## TL;DR: how to self-host GitLab Self-hosting GitLab gives you control over where GitLab runs, how it is configured, and where your source code and development data are stored. With [Northflank](https://northflank.com), you can deploy a self-hosted GitLab instance using a one-click template without manually configuring the underlying application infrastructure. There are two templates available: 1. [**GitLab Community Edition**](https://northflank.com/stacks/deploy-gitlab-ce): Deploy the open-source Community Edition. 2. [**GitLab Enterprise Edition**](https://northflank.com/stacks/deploy-gitlab-ee): Deploy GitLab Enterprise Edition for organizations that need its additional enterprise capabilities. You can deploy GitLab on [Northflank's managed cloud](https://northflank.com/features/managed-cloud) or use [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud) to deploy it into your own cloud environment. This guide uses **Northflank Cloud** for the deployment. > **What is Northflank?** [Northflank](https://northflank.com/) is a cloud platform for deploying and managing applications, databases, GPUs, and infrastructure. Its one-click templates let you deploy preconfigured application stacks without building the infrastructure from scratch. You can also deploy workloads into your own cloud through [BYOC](https://northflank.com/product/bring-your-own-cloud). [Get started with Northflank](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > GitLab gives teams a complete platform for source code management, CI/CD, project management, and DevSecOps. GitLab's managed platform is the simplest way to get started, but some teams need more control over where GitLab runs, how their data is stored, and how it connects to their existing infrastructure. Self-hosting GitLab gives you that control, but it also means taking responsibility for the infrastructure behind it. This guide explains why you might self-host GitLab, what you need to run it, and how to deploy a GitLab Community Edition or Enterprise Edition instance using a one-click Northflank template. ## Why self-host GitLab? GitLab's managed platform is the simplest way to get started with GitLab because GitLab manages the underlying infrastructure for you. Self-hosting becomes useful when your organization needs more control over the environment where GitLab runs. The main reasons to self-host GitLab include: - **Data control:** Keep your Git repositories, project data, and supporting services within infrastructure you control. - **Infrastructure control:** Choose where GitLab runs, including the cloud provider, region, and infrastructure configuration. - **Network requirements:** Run GitLab within a private network or alongside internal applications and services. - **Security and compliance:** Apply your organization's infrastructure, identity, networking, and security controls to your GitLab deployment. - **Customization:** Configure GitLab and its supporting infrastructure according to your organization's requirements. - **Cloud flexibility:** Use existing cloud infrastructure or commitments rather than relying exclusively on a SaaS environment. - **Operational control:** Decide how GitLab is deployed, updated, backed up, monitored, and managed. The tradeoff is that self-hosting makes your team responsible for operating the GitLab environment. You need to think about storage, backups, updates, networking, security, monitoring, and availability. For small teams that simply need Git hosting and CI/CD, GitLab's managed platform may be easier. For organizations with infrastructure, security, or data requirements that make a managed SaaS platform unsuitable, self-hosting can provide significantly more control. ## What you need to self-host GitLab For a Docker-based installation, you'll need the following: - **Docker:** GitLab is distributed as a Docker image, so you need Docker Engine and Docker Compose if you're following the standard Docker Compose setup. - **A hostname:** GitLab requires a hostname that resolves to the server where GitLab is running. The hostname is used to configure GitLab's `external_url`. - **Persistent storage:** GitLab stores its configuration, logs, and application data in `/etc/gitlab`, `/var/log/gitlab`, and `/var/opt/gitlab`. These directories should use persistent storage so data survives container restarts or replacements. - **Sufficient compute and memory:** GitLab is a relatively resource-intensive application, so the host needs enough CPU and memory for the GitLab services and the workloads you expect to run. - **Network access:** The GitLab instance needs the appropriate ports exposed for web access and, if required, SSH access for Git operations. - **A GitLab edition:** You can self-host either GitLab Community Edition or Enterprise Edition, depending on the features and licensing requirements of your organization. **Using the Northflank stack template?** The GitLab [Community Edition](https://northflank.com/stacks/deploy-gitlab-ce) and [Enterprise Edition](https://northflank.com/stacks/deploy-gitlab-ee) templates handle the Docker deployment, persistent volumes, networking, health checks, and GitLab configuration for you. You only need to choose the edition and version, review the deployment settings, and deploy it to Northflank. ## How to self-host GitLab The easiest way to self-host GitLab on Northflank is to use one of the preconfigured GitLab stack templates. You can choose between Community Edition and Enterprise Edition and deploy either directly to Northflank Cloud or to your own cloud through BYOC. ### Step 1: Create a Northflank account [Sign up for Northflank](https://app.northflank.com/signup) and create a team for your GitLab deployment. GitLab requires a significant amount of compute and persistent storage to run reliably, so you may need to upgrade your Northflank plan depending on your deployment requirements. ### Step 2: Choose a GitLab template Northflank provides one-click deployment templates for both GitLab Community Edition and GitLab Enterprise Edition: 1. [**GitLab Community Edition**](https://northflank.com/stacks/deploy-gitlab-ce): Deploy the open-source Community Edition. 2. [**GitLab Enterprise Edition**](https://northflank.com/stacks/deploy-gitlab-ee): Deploy Enterprise Edition with its additional enterprise features. The deployment process is the same for both editions. Choose the edition you want to deploy and click **`Deploy {edition} now`**. ### Step 3: Deploy the GitLab template For this guide, we'll deploy **GitLab Community Edition**. ![image.png](https://assets.northflank.com/image_255739afb6.png) 1. The template uses GitLab version `19.0.8-ce.0` by default. You can select a different version in the stack configuration before deploying. 2. Review the stack configuration and click **`Deploy stack`**. 3. Northflank provisions the GitLab project, service, persistent volume, and required configuration. 4. Once the deployment is complete, click **`Resource`**. 5. Open the **GitLab Service**. 6. Open the generated public domain to access your GitLab instance. ![image 1.png](https://assets.northflank.com/image_1_50dcf87290.png) GitLab can take several minutes to initialize on first startup. The service must complete its initialization and pass its readiness check before the GitLab UI becomes available. ![image 2.png](https://assets.northflank.com/image_2_b5027f636a.png) **Note:** The initial GitLab deployment can take around 10 minutes or longer before the GitLab UI is accessible. This is expected during the first startup. ### Step 4: Get the GitLab administrator password GitLab generates an initial password for the `root` administrator account when the instance is first initialized. You can retrieve it from the GitLab service shell. 1. From the **GitLab Service** dashboard, open **Observe** under **Observability**. 2. Select **Shell**. 3. Run the following command: `grep 'Password:' /etc/gitlab/initial_root_password` 4. Copy the generated password. ![image 3.png](https://assets.northflank.com/image_3_d40d8bbccc.png) You can now open your GitLab instance and sign in with: - **Username:** `root` - **Password:** The password returned by the command above. After signing in, change the initial password and configure your GitLab instance according to your organization's requirements. ![image 4.png](https://assets.northflank.com/image_4_90fe0851c2.png) ## How to manage a self-hosted GitLab instance Once GitLab is deployed, you can manage the instance and its underlying infrastructure directly from the Northflank dashboard. Key areas include: - **Service management:** Start, restart, redeploy, and monitor the GitLab service from the Northflank dashboard. - **Resource management:** Adjust the compute resources allocated to GitLab as your users, repositories, and workloads grow. - **Persistent storage:** Manage the volume attached to GitLab and increase its capacity when you need additional storage. - **Environment configuration:** Update GitLab configuration and environment variables through the service configuration and secret groups. - **Networking and domains:** Manage the public domain and configure custom domains for your GitLab instance. - **Logs and observability:** Use Northflank's observability tools to inspect GitLab logs, access the service shell, and troubleshoot issues. - **GitLab versions:** Update the GitLab image version when you want to upgrade your deployment. Review GitLab's upgrade requirements before changing versions. - **Deployment configuration:** Modify the deployment configuration as your requirements change, including compute, storage, networking, and other service settings. - **Cloud infrastructure:** If you're using BYOC, manage the GitLab workload in your own cloud environment while continuing to manage the deployment through Northflank. **Managing GitLab with Northflank:** You can manage the GitLab service and its underlying infrastructure from the Northflank dashboard. Adjust compute and storage, inspect logs, access the service shell, manage configuration, update the deployment, and configure domains without manually managing the underlying container orchestration. ## FAQ: How to self-host GitLab ### Is it free to self-host GitLab? The GitLab software and the infrastructure it runs on are separate considerations. Community Edition is available for self-managed deployments, but you still need to provide the compute, storage, networking, and other infrastructure required to operate the instance. ### Can I self-host GitLab on AWS? Yes. GitLab can be deployed in your AWS environment. With Northflank BYOC, you can deploy GitLab into your own cloud environment while continuing to manage the deployment through the Northflank platform. ### Can I self-host GitLab without managing Kubernetes? Yes. You can use a deployment platform that manages the underlying orchestration layer for you. Northflank abstracts much of the underlying infrastructure management, so you can deploy and operate GitLab without manually managing Kubernetes. ### Should I use GitLab Community Edition or Enterprise Edition? It depends on the capabilities your organization needs. Community Edition provides the core GitLab platform, while Enterprise Edition is intended for organizations that need additional enterprise capabilities. Choose the edition that matches the features and licensing requirements of your team. ### Can I deploy GitLab with one click? Yes. Northflank provides one-click GitLab templates that package the resources and configuration required for the deployment. You can choose between Community Edition and Enterprise Edition, review the configuration, and deploy the instance without manually creating each underlying resource. ### Can I deploy self-hosted GitLab in my own cloud? Yes. Northflank BYOC allows you to deploy GitLab into your own cloud environment instead of Northflank Cloud. You retain control over the underlying cloud infrastructure while managing the GitLab deployment through Northflank. ### How do I back up a self-hosted GitLab instance? Your backup strategy should cover the persistent data required to restore GitLab. For a production instance, define your backup frequency, retention, storage location, and recovery process, and test your backups regularly to make sure you can restore the instance when needed. ### Should I use GitLab's managed platform or self-host GitLab? GitLab's managed platform is generally simpler if you want GitLab without managing the underlying infrastructure. Self-hosted GitLab gives you more control over infrastructure, networking, and data location, but also means taking responsibility for backups, updates, security, and maintenance. If you need that additional control without building the entire deployment infrastructure yourself, you can use a Northflank GitLab template to deploy GitLab on Northflank Cloud or in your own cloud through BYOC. ## Conclusion Self-hosting GitLab gives you greater control over where GitLab runs, how it connects to your infrastructure, and how your development data is managed. However, that control also comes with the responsibility of maintaining the instance, including backups, updates, security, and monitoring. With [Northflank](https://northflank.com/), you can simplify the initial deployment using a one-click GitLab Community Edition or Enterprise Edition template. The templates provision the GitLab service, persistent storage, networking, and required configuration, while giving you the option to run GitLab on Northflank Cloud or in your own cloud through BYOC. **Ready to self-host GitLab?** Deploy GitLab on Northflank using the [Community Edition](https://northflank.com/stacks/deploy-gitlab-ce) or [Enterprise Edition](https://northflank.com/stacks/deploy-gitlab-ee) template, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your deployment requirements.

Best GitHub alternatives in 2026

2026-08-19T15:00:00.000Z

## TL;DR: What are the best GitHub alternatives in 2026? The best GitHub alternative depends on what you need from your source control platform: 1. **GitHub Enterprise Server:** The closest option if you want the GitHub experience and ecosystem while running GitHub in your own infrastructure. 2. **GitLab:** A full-featured GitHub alternative with hosted and self-managed options, combining Git hosting, CI/CD, security, project management, and DevSecOps capabilities. 3. **Bitbucket:** A strong choice for teams already using Jira, Confluence, and other Atlassian tools. 4. **Azure DevOps:** A good fit for organizations that already use Microsoft's development and cloud ecosystem. 5. **Gitea:** A lightweight self-hosted Git service for teams that want a familiar GitHub-like experience without the resource requirements of GitLab. 6. **Cursor Origin:** An emerging code hosting platform designed around AI agent workflows. It is still early and is most relevant to teams already using Cursor. > **Northflank is a cloud platform for deploying and running applications and infrastructure, either on Northflank's managed cloud or in your own cloud using BYOC.** You can self-host GitHub Enterprise Server, GitLab, or Gitea on Northflank, with one-click deploy stack templates available for [GitLab Community Edition](https://northflank.com/stacks/deploy-gitlab-ce) and [GitLab Enterprise Edition](https://northflank.com/stacks/deploy-gitlab-ee). You can also connect your existing source control platform to Northflank for CI/CD and deployments. [Get started with Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > GitHub has had a rough run in 2026. On August 17, 2026, the platform suffered a roughly [six-and-a-half-hour outage](https://www.githubstatus.com/incidents/zkxwbgr0cnmx), with error rates approaching 20% across GitHub services and file downloads failing at nearly 50%. For teams that rely on GitHub for source control, CI/CD, and code review, incidents like this can bring development workflows to a halt. GitHub is still the dominant code hosting platform, but its recent reliability issues, alongside concerns around platform dependency, data control, and cost, have made GitHub alternatives worth considering. At the same time, new platforms such as Cursor Origin are exploring what code hosting looks like when AI agents become a central part of software development. This guide compares the best GitHub alternatives in 2026 and explains which one makes the most sense for your team. ## Why teams are looking at GitHub alternatives in 2026 GitHub remains one of the most widely used platforms for source control, collaboration, and CI/CD. But a string of incidents, growing platform dependency, and the shift toward AI-assisted development are making teams question whether GitHub should remain the foundation of their entire development workflow. ### 1. Recent GitHub outages The reliability concerns are hard to ignore. [On August 17, 2026](https://www.githubstatus.com/incidents/zkxwbgr0cnmx), GitHub suffered a major outage that affected web experiences, API traffic, GitHub Actions, pull requests, webhooks, authentication, and repository downloads. Error rates reached around 20% across some services, while repository content and archive downloads saw failure rates of around 50%. This was not an isolated incident. [IncidentHub](https://blog.incidenthub.cloud/github-reliability-outage-history-2025-2026) recorded 257 GitHub incidents between May 2025 and April 2026, including 48 major outages. February 2026 was the worst month in that period with 37 incidents, while GitHub Actions accounted for 57 incidents. Some incidents have had a direct impact on development and deployment. [GitHub's May 2026 availability report](https://github.blog/news-insights/company-news/github-availability-report-may-2026/), for example, documented an incident where 42% of GitHub Actions runs failed at peak impact. GitHub is aware of the scaling challenge. In [April 2026](https://github.blog/news-insights/company-news/an-update-on-github-availability/), its CTO said the company had started planning for 10x more capacity before determining that it needed to design for 30x today's scale. GitHub attributed much of that growth to agentic development, including increases in repository creation, pull requests, API usage, and automation. For teams that rely on GitHub for source control, CI/CD, code review, and AI tooling, the question is no longer simply whether GitHub is convenient. **What happens to your development workflow when the platform it depends on goes down?** ### 2. Data and infrastructure control Self-hosting gives organizations more control over where their source code and development data live. This can be important for teams with data residency requirements, internal security policies, regulated workloads, or infrastructure that needs to remain within a specific cloud or private network. The tradeoff is that self-hosting also means taking responsibility for the infrastructure, updates, backups, and security. ### 3. Reducing platform dependency Modern development workflows can depend heavily on a single platform. A team might use GitHub for source control, GitHub Actions for CI/CD, GitHub Advanced Security for vulnerability scanning, and GitHub Copilot for AI-assisted development. That integration is convenient, but it also creates a single point of dependency. Pricing changes, product decisions, policy changes, or another major outage can affect multiple parts of your development workflow at once. ### 4. The rise of AI-assisted development AI is also changing what teams expect from code hosting platforms. GitHub is expanding Copilot and agentic development capabilities, while the company says these workflows are already driving significant increases in repository creation, pull requests, API traffic, and automation. At the same time, platforms such as Cursor Origin are taking a different approach, building around AI agents rather than adding AI capabilities to an existing human-focused code hosting workflow. GitHub is not going away, but the way developers build and collaborate is changing. That makes 2026 a good time to look at what the alternatives can offer. ## What to look for in a GitHub alternative Not every GitHub alternative solves the same problem. Before migrating, consider the capabilities your team actually depends on. - **Availability and reliability:** Consider the platform's track record for uptime and how it handles outages. If your entire development workflow depends on your code hosting platform, repeated outages can block code pushes, CI/CD pipelines, pull requests, and deployments. Self-hosted platforms also require you to consider the reliability of the infrastructure you run them on. - **Self-hosting and data residency:** If you are moving away from GitHub because of data control or compliance requirements, make sure the alternative can run in your environment. Check whether you can deploy it on premises, in your own cloud account, or in a specific region. - **CI/CD compatibility:** CI/CD can be one of the hardest parts of a migration. If your organization has hundreds of GitHub Actions workflows, moving to a platform with a completely different CI/CD system can require significant changes. Gitea supports GitHub Actions-compatible workflow syntax, while GitLab uses its own CI/CD configuration system. - **Authentication and access control:** Enterprise teams should evaluate support for the identity systems they already use. Look for capabilities such as SAML SSO, OIDC, LDAP, role-based access control, audit logs, and organization or team management. - **Pull requests and code review:** Source control is only part of the development workflow. Code review, pull requests, branch protection, approvals, and collaboration are equally important. A platform may support Git repositories but still create significant friction if its review workflow is very different from what your developers are used to. - **Integrations:** Check whether the tools your team relies on integrate with the alternative. This includes deployment platforms, issue trackers, security tools, IDEs, chat platforms, package registries, and other development services. - **AI tooling:** If your team relies heavily on Cursor, Claude Code, GitHub Copilot, or other AI coding tools, check how well they work with your chosen platform. This is becoming increasingly important as AI agents become more involved in creating pull requests, reviewing code, and managing repositories. ## What are the best GitHub alternatives in 2026? ### 1. GitHub Enterprise Server GitHub Enterprise Server is GitHub's self-hosted offering. Instead of moving to another code hosting platform, you keep GitHub's familiar interface and ecosystem while running it in your own infrastructure. This makes it the most straightforward option for organizations that like GitHub but need more control over where it runs. **What it provides** GitHub Enterprise Server provides the familiar GitHub experience for repositories, pull requests, issues, code review, and collaboration. It also supports GitHub Actions, enterprise authentication, access controls, and other capabilities organizations expect from GitHub. **The limitations** The biggest advantage is also the biggest limitation: you are still using GitHub. GitHub Enterprise Server is proprietary and intended for enterprise customers, so you remain dependent on GitHub's software, release cycle, licensing, and ecosystem. Your organization is also responsible for operating the underlying infrastructure. **Best for** GitHub Enterprise Server is best for large organizations that want GitHub's ecosystem and developer experience but need to run their code hosting platform in their own infrastructure. **Self-host GitHub Enterprise Server on Northflank** You can run GitHub Enterprise Server on Northflank and use Northflank as the infrastructure and deployment layer. Northflank supports self-hosted GitHub Enterprise as a version control system, allowing you to connect your instance and build and deploy repositories through the platform. [Get started with Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ### 2. GitLab GitLab is one of the most complete alternatives to GitHub. It combines source control, merge requests, CI/CD, project management, security tooling, package registries, container registries, and DevSecOps capabilities in a single platform. Unlike alternatives that focus primarily on self-hosting, GitLab gives teams a choice between using a managed service and running GitLab in their own infrastructure. **What it provides** GitLab provides Git repositories, merge requests, issue tracking, CI/CD, package and container registries, security tooling, and project management. For teams that want their source control, CI/CD, security, and development tooling in one platform, GitLab is one of the closest alternatives to GitHub. **The limitations** GitLab's broad feature set can make it feel more complex than lightweight alternatives such as Gitea. Self-managed deployments also require teams to take responsibility for infrastructure, updates, backups, and availability. **Best for** GitLab is best for teams that want a complete development and DevSecOps platform and want the flexibility to use it as either a managed or self-hosted service. **Self-host GitLab on Northflank** You can [self-host GitLab on Northflank](https://northflank.com/blog/how-to-self-host-git-lab) using a preconfigured one-click deploy [Community Edition](https://northflank.com/stacks/deploy-gitlab-ce) or [Enterprise Edition](https://northflank.com/stacks/deploy-gitlab-ee) stack template. [Get started with Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ### 3. Bitbucket Bitbucket is Atlassian's Git-based source code hosting platform. Its biggest advantage is its integration with the wider Atlassian ecosystem, particularly Jira and Confluence. For teams already using Atlassian products for project management and documentation, Bitbucket can provide a more integrated development workflow than moving to an entirely separate ecosystem. **What it provides** Bitbucket provides Git repositories, pull requests, code review, CI/CD through Bitbucket Pipelines, and integrations with Jira and other Atlassian products. Its connection to Jira is particularly useful for teams that want development work, issues, and project tracking connected in one workflow. **The limitations** Bitbucket is most compelling when you are already invested in the Atlassian ecosystem. Teams that do not use Jira or other Atlassian products may find fewer reasons to choose it over alternatives such as GitLab. **Best for** Bitbucket is best for teams already using Jira, Confluence, or other Atlassian products that want their source control and project management workflows tightly integrated. ### 4. Azure DevOps Azure DevOps is Microsoft's suite of development tools, combining source control, CI/CD, project management, testing, and package management. It is particularly attractive for organizations already invested in Microsoft technologies and Azure. **What it provides** Azure DevOps includes Azure Repos for Git hosting, Azure Pipelines for CI/CD, Boards for project management, Test Plans, and Artifacts for package management. Teams can use Azure DevOps as a broader development platform rather than simply replacing GitHub's repository hosting. **The limitations** Azure DevOps has a different workflow and interface from GitHub, so teams migrating from GitHub may need time to adapt. It can also be more than teams need if their primary requirement is simply Git hosting and pull requests. **Best for** Azure DevOps is best for organizations already using Azure and Microsoft development tools that want source control, CI/CD, project management, and testing in one ecosystem. ### 5. Gitea Gitea is a lightweight, open source Git hosting platform written in Go. It provides repositories, pull requests, issues, wikis, package registries, and other features needed to run a self-hosted development platform. Compared with GitLab, Gitea focuses on keeping the core platform lightweight and easy to operate. **What it provides** Gitea provides a GitHub-like interface for repositories, issues, pull requests, wikis, and project management. It also includes Gitea Actions, which uses GitHub Actions-compatible workflow syntax, making it easier to migrate existing workflows. The platform also supports package registries, Git LFS, OAuth2, OIDC, LDAP, and a REST API. **The limitations** Gitea is intentionally smaller than GitLab, which means it does not provide the same breadth of integrated DevSecOps capabilities. Teams that need advanced security scanning, extensive compliance tooling, or a large collection of integrated enterprise features may find GitLab a better fit. **Best for** Gitea is best for teams that want lightweight self-hosted Git infrastructure without the operational and resource requirements of a larger DevSecOps platform. **Self-host Gitea on Northflank** You can run Gitea on Northflank and use Northflank as the infrastructure layer for your self-hosted Git platform. Northflank also integrates with Gitea for CI/CD and deployment workflows, so you can keep your source control and application deployment workflows connected. [Get started with Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ### 6. Cursor Origin Cursor is taking a different approach to code hosting with Origin, an agent-focused code hosting and collaboration platform. Origin is particularly interesting because it is being designed around AI agents rather than treating AI as an additional feature on top of an existing human-focused development workflow. It launched to paid Cursor users on August 17, 2026, making it one of the newest options in this category. **What it provides** Origin is designed around collaborative coding, code review, pull requests, repository management, and AI agent workflows. The platform is intended to work alongside GitHub rather than requiring an immediate migration. This allows teams to experiment with the workflow without immediately replacing their existing GitHub infrastructure. **The limitations** Origin is still very early. Its feature set is not yet comparable to mature platforms such as GitHub or GitLab, and its usefulness is closely tied to the Cursor ecosystem. It is therefore better viewed as an emerging option for AI-focused teams than as a direct replacement for GitHub today. It also does not provide a self-hosted deployment option. **Best for** Cursor Origin is worth watching for teams that already use Cursor extensively and want their source control and code collaboration workflow to become more tightly integrated with AI agents. For most teams today, it is too early to treat Origin as a complete replacement for GitHub. ## How to choose the right GitHub alternative The right option depends on why you are considering leaving GitHub in the first place. **If you want the most complete GitHub alternative:** Choose **GitLab**. It provides source control, CI/CD, security, project management, and DevSecOps capabilities, with both managed and self-hosted options. **If your team uses Jira and Atlassian heavily:** Choose **Bitbucket**. Its integration with Jira and the wider Atlassian ecosystem makes it a natural fit. **If you're already invested in Microsoft and Azure:** Choose **Azure DevOps**. It combines source control, CI/CD, project management, testing, and package management. **If you want GitHub's experience in your own infrastructure:** Choose **GitHub Enterprise Server**. It keeps the GitHub workflow while giving your organization control over the deployment environment. **If you want lightweight self-hosted Git hosting:** Choose **Gitea**. It requires fewer resources and provides the core repository and collaboration features most teams need. **If your development workflow is increasingly AI agent-driven:** Keep an eye on **Cursor Origin**. It is designed around agent-first development, but it is still too early to make it your primary code hosting platform. **If GitHub Actions compatibility is critical:** Gitea is worth considering because of its GitHub Actions-compatible workflow syntax. GitLab CI is a capable alternative, but migrating existing Actions workflows will generally require more changes. ## Conclusion GitHub remains the dominant code hosting platform, but its recent reliability issues and the rise of AI-driven development have made it worth reconsidering how much of your development workflow depends on a single platform. **GitLab** is the strongest general-purpose alternative, while **Bitbucket** and **Azure DevOps** make more sense for teams already invested in their respective ecosystems. For teams that need more infrastructure control, **GitHub Enterprise Server** and **Gitea** provide self-hosted options, while **Cursor Origin** is one to watch as AI agents become a bigger part of software development. If you're moving away from GitHub, you don't necessarily need to rebuild your deployment infrastructure at the same time. **Northflank provides the infrastructure layer for self-hosting GitLab, GitHub Enterprise Server, or Gitea, while also integrating with existing source control platforms for CI/CD and deployments.** This lets you choose where your code lives while keeping your application deployment workflow consistent. [Get started with Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ## FAQ: Best GitHub alternatives in 2026 ### What is the best free self-hosted alternative to GitHub? GitLab Community Edition and Gitea are both strong free self-hosted alternatives. GitLab provides a broader DevSecOps platform, while Gitea is better suited to teams that want lightweight Git hosting with lower infrastructure requirements. ### What is the easiest GitHub alternative to self-host? Gitea is generally one of the simplest options to self host because of its lightweight architecture and relatively small resource requirements. GitLab provides more functionality but requires more resources and operational planning. ### Can I migrate my GitHub repositories to another platform? Yes. GitLab and Gitea provide migration tools for moving repositories from GitHub. Git repositories themselves are portable, but you should also plan how to migrate issues, pull requests, wikis, secrets, webhooks, and CI/CD workflows. ### Can I use GitHub Actions with GitHub alternatives? It depends on the platform. Gitea supports GitHub Actions-compatible workflow syntax, which can reduce migration work. GitLab uses GitLab CI/CD with its own configuration format, so GitHub Actions workflows generally need to be adapted. ### Is Cursor Origin a replacement for GitHub? Not yet. Cursor Origin is an emerging code hosting platform designed around AI agent workflows, but it is still early and does not yet offer the breadth of features and ecosystem integrations available from GitHub or GitLab. It is most relevant to teams already using Cursor that want to experiment with an agent-first development workflow. ### Should I use GitHub Enterprise Server or GitLab? Choose GitHub Enterprise Server if maintaining the GitHub experience and ecosystem is your priority. Choose GitLab if you want a broader self-hosted DevSecOps platform with integrated CI/CD, security, project management, and development tooling. ### Is self-hosting Git repositories more reliable than using GitHub? Not automatically. A self-hosted Git service is only as reliable as the infrastructure, backups, monitoring, redundancy, and operational practices behind it. The advantage is control: you decide how the system is deployed, where it runs, how it is backed up, and how it recovers from failures, while avoiding a platform-wide outage affecting your organization simply because the hosted provider is unavailable.

How to connect an AI-built app to private APIs inside a corporate network

2026-08-18T16:00:00.000Z

An AI-built app may work in preview but fail in production because an API inside your organization-controlled cloud or on-premises network is not publicly routable. Publishing a private API on the internet or giving the app access to a broad segment of your private network can expand its attack surface and network reachability. This article covers the main ways to connect an AI-built app to private APIs in your organization’s network, when each approach fits your team, and the controls needed to operate the connection safely in production. ## TL;DR: How to connect an AI-built app to private APIs inside a corporate network Connect the app through a bounded path to required private APIs, then authenticate workloads and authorize API actions independently of network location. - Deploy the app into a connected VPC in your cloud account when you need existing private routes or infrastructure control. - Use a private overlay or outbound connector when the app and private APIs remain in separate networks. - Put a narrow gateway at the private network boundary when you want to expose approved business operations instead of wider network access. - Use static egress IP allowlisting only for reachable APIs, alongside appropriate identity and authorization controls. - Test DNS, routes, denied actions, credential revocation, connector failure, and containment before production. If your organization needs AI-built apps to access private services, [Northflank](https://northflank.com/) gives your team a full-stack cloud platform for building, deploying, and operating them on [Northflank’s managed cloud](https://northflank.com/cloud/northflank) or [your own infrastructure](https://northflank.com/features/bring-your-own-cloud). Choose the connectivity option that fits your architecture. When your app and private API run in separate networks, use Northflank’s [Tailscale integration](https://northflank.com/docs/v1/application/network/use-tailscale) to give selected managed-cloud workloads access to approved devices and connected networks. For a reachable API protected by firewall allowlisting, route selected workloads through a [dedicated egress IP](https://northflank.com/docs/v1/application/network/configure-egress-ips). When the app needs to run in your cloud account and use its existing private routes, deploy it with self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud). Teams of any size can choose the deployment and connectivity options that meet their architecture, security, and compliance requirements. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## Why can’t the AI-built app call the private API directly? A deployed app can call a private API when its runtime has an approved network path and can resolve or otherwise address the private endpoint. That path should create a deliberately small security boundary. There are five separate layers to the connection: - **Name resolution:** The app resolves the private API hostname to the intended internal address. - **Network routing:** The app has a route to that address and the intervening firewalls permit the required protocol and port. - **Transport security:** TLS or mTLS protects the request in transit where required and verifies that the app reached the intended peer. - **Workload authentication:** The API can establish which application or service made the request. - **API authorization:** The API decides which functions, objects, and fields that caller may access. Network connectivity proves reachability, not permission. [NIST’s zero-trust guidance for cloud-native applications](https://csrc.nist.gov/pubs/sp/800/207/a/final) treats network location as insufficient and bases access policies on application and service identities. Your API should authorize the requested resource even when traffic arrives through a private route. If the app handles sensitive records, treat networking as one part of the wider process for [connecting AI-built apps to company data securely](https://northflank.com/blog/connect-vibe-coded-apps-company-data-securely). ## Which private connectivity pattern should you choose for an AI-built app? Choose the pattern that grants the narrowest reliable access while fitting your existing cloud routes, network ownership, latency, availability, and incident-response model. | Pattern | Best fit | Network exposure | Main trade-off | | --- | --- | --- | --- | | App in a connected VPC | Production apps that need existing private routes and customer-controlled infrastructure | Approved VPC and internal routes | Cloud networking and IP-range planning | | Private overlay or outbound connector | Apps and APIs in separate networks without inbound access to the private network | Selected devices, services, or advertised subnets | Connector lifecycle, routing, and DNS operations | | Narrow API gateway or proxy | Teams that want operation-level exposure rather than subnet routing | Approved API operations | Gateway availability and policy design | | Static egress IP allowlist | Reachable APIs that accept known source IPs | The reachable API endpoint | Coarse source control, not private routing or authorization | ## How does each pattern connect an AI-built app to private APIs inside your organization’s network? Each pattern creates a different boundary between your AI-built application and private APIs. The best choice depends on what should become reachable and which team will operate the connection. ### 1. Deploy the app into a connected VPC Run the application in a VPC in your cloud account that connects to your organization’s private network through routing, peering, a transit network, or a site-to-site VPN. Keep the app on private subnets where appropriate and permit only the required API destinations and ports. Check address ranges before deployment because overlapping CIDRs can prevent routing or send traffic to the wrong network. Define how the runtime resolves private names and what happens when the internal DNS resolver is unavailable. If your company wants to use those routes without giving builders direct cloud-console access, a Northflank [BYOC project](https://northflank.com/docs/v1/application/bring-your-own-cloud/deploy-workloads-to-your-cluster) can place services and jobs on a cluster in your cloud account and VPC. Workload runtime and data remain there; assess control-plane metadata, logs, builds, images, DNS, and backups separately. When you sell software that needs to run inside each customer’s own cloud account or on-premises environment, [Northflank Customer VPC Deployments](https://northflank.com/product/customer-vpc-deployments) lets you deploy and manage it across those environments using the same application definition. ### 2. Attach the app through a private overlay or outbound connector Use a private overlay or connector when the app and private API remain in separate networks. Limit which workloads join the overlay, advertise only the required subnet routes where practical, and restrict them to the required destinations and ports. Your design should cover connector redundancy, route ownership, key rotation, private DNS, and failure behavior. Decide whether a failed route should stop requests or allow a controlled retry, and make sure it does not fall back to an unapproved public path. If a Tailscale overlay fits your network, use Northflank’s [Tailscale integration](https://northflank.com/docs/v1/application/network/use-tailscale) to connect only your application workloads that need access to tailnet devices and resources behind accepted subnet routes. Use [Tailscale grants](https://tailscale.com/docs/features/access-control/grants) or ACLs to restrict which destinations and ports those workloads may reach. A new tailnet uses an allow-all policy until you configure access controls. Do not assume that a private API behind a subnet router will see a unique application source IP. Tailscale subnet routers use source NAT by default, so use application or workload credentials when the API needs to identify the caller. ### 3. Put a narrow API gateway at the private network boundary Place a gateway or purpose-built proxy at the boundary when your security team wants to make approved API operations available to the app without giving it broader private-network reachability. For example, expose `GET /customers/{id}/open-tickets` to a support app instead of providing a generic proxy that accepts arbitrary internal URLs. The gateway should authenticate the workload, validate relevant user context, authorize the operation and object, enforce schemas and limits, and filter fields. Keep destinations fixed or allowlisted. [OWASP API7:2023](https://owasp.org/API-Security/editions/2023/en/0xa7-server-side-request-forgery/) identifies server-side request forgery as a risk when an application fetches a user-supplied URL without validating its destination. If your team chooses Northflank for the app and gateway, a [private port](https://northflank.com/docs/v1/application/network/configure-ports#private-ports) can make the gateway available within the project. When the components need separate projects in the same team and cluster, [multi-project networking](https://northflank.com/docs/v1/application/network/enable-multi-project-networking) can permit one-way ingress from the approved project without publishing the gateway on the internet. These controls cover the app-to-gateway leg; the gateway still needs an approved route or overlay connection to the private API. ### 4. Use static egress allowlisting when the API is reachable from the app Use static egress allowlisting when the API is reachable and its firewall accepts known source IPs. A dedicated egress IP gives your app a stable address for that rule. It does not create a route to an internal-only address or authenticate a workload. Treat it as a network filter and apply workload credentials and API policy. If your team needs managed app infrastructure and API firewall allowlisting, Northflank’s managed cloud can route a service or job through a [dedicated egress IP](https://northflank.com/docs/v1/application/network/configure-egress-ips). Restrict which workloads use the address and share it with the API owner. To run the app in your own cloud account, deploy it on a Northflank BYOC cluster and [configure static egress for workloads on your AWS, GCP, or Azure BYOC cluster](https://northflank.com/docs/v1/application/bring-your-own-cloud/configure-static-egress-ips). This gives your workloads a fixed outbound IP that the API owner can allowlist. ## How should you test an AI-built app’s private API connection before production? Test the complete path under allowed, denied, degraded, and compromised conditions. A successful response proves the happy path, but it does not show whether the connection fails safely. - Confirm that internal DNS resolves in approved runtimes without falling back to an unintended address. - Attempt access from an unapproved workload, project, or environment. - Request unapproved hosts, ports, API functions, objects, and fields. - Send user-controlled URLs and redirects to test SSRF protections. - Confirm certificate, hostname, and mTLS identity validation where used. - Expire or revoke the workload credential and confirm that requests stop. - Stop each connector or route and confirm failure does not trigger an unapproved fallback. - Exercise payload, response, rate, concurrency, timeout, and retry limits. - Trace one request across app, network control, gateway, and private API logs. Use production-equivalent routing and policy without production credentials. Assign owners for disabling connections, revoking credentials, blocking clients, and stopping apps. Your logs should correlate relevant users, workload identity, destination, operation, policy result, status, and affected resource. Record request or response bodies only when policy permits. Keep platform infrastructure events, including Northflank audit events, separate from the business requests and authorization decisions recorded by your gateway and private API. ## How does Northflank connect AI-built apps to private APIs inside your organization’s network? Northflank lets your team deploy an AI-built app and control how it reaches private services on [Northflank’s managed cloud](https://northflank.com/features/managed-cloud) or [your own infrastructure](https://northflank.com/features/bring-your-own-cloud), alongside secrets, access controls, network restrictions, and audit evidence. - **Choose where the app runs:** Start on [Northflank’s managed cloud](https://northflank.com/features/managed-cloud), or use [BYOC](https://northflank.com/features/bring-your-own-cloud) when the app needs to run in your cloud account and use your existing private routes. If you sell software that must run in customer environments, [Customer VPC Deployments](https://northflank.com/product/customer-vpc-deployments) lets you deploy the same application across customer cloud and on-premises infrastructure. - **Connect networks without making the API public:** If the app and API remain in separate networks, connect only the workloads that need access through [Tailscale](https://northflank.com/docs/v1/application/network/use-tailscale), then control the permitted devices, subnet routes, destinations, and ports. - **Limit what the app can reach:** When you deploy with BYOC, [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies) can restrict egress to approved workloads, projects, IP ranges, or hostnames. With no egress rules, traffic is allowed; adding a rule creates an allowlist for that direction. - **Provide an IP for firewall allowlisting:** For a reachable API that accepts only known sources, route selected managed-cloud workloads through a [dedicated egress IP](https://northflank.com/docs/v1/application/network/configure-egress-ips). For a BYOC cluster, [configure static egress in your AWS, GCP, or Azure network](https://northflank.com/docs/v1/application/bring-your-own-cloud/configure-static-egress-ips). - **Keep internal services off the public internet:** Use [private project ports](https://northflank.com/docs/v1/application/network/configure-ports#private-ports) for communication between the app, gateway, workers, and other services. Use [multi-project networking](https://northflank.com/docs/v1/application/network/enable-multi-project-networking) when approved components are separated across projects in the same team and cluster. - **Control credentials and platform access:** [Inject secrets](https://northflank.com/docs/v1/application/secure/inject-secrets) only into the workloads that need them, use [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control) and [scoped API roles](https://northflank.com/docs/v1/application/secure/grant-api-access) to control infrastructure access, and use [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) for Northflank platform events. Keep business requests and API authorization decisions separate. - **Support compliance and residency:** Northflank is [SOC 2 Type 2 and HIPAA compliant](https://northflank.com/security), with BAAs supported under Enterprise contracts. BYOC keeps workload runtime and data in your cloud environment. - **Work from your AI coding tool:** If you use a compatible coding agent, install [Northflank Skills](https://github.com/northflank/skills) to give it Northflank-specific guidance for deploying, operating, and automating workloads through the CLI or API. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss private API routes, workload identity, cloud placement, and network policy. ## Frequently asked questions about connecting AI-built apps to private APIs These answers clarify common implementation decisions. ### Does the AI-built app need to run inside the corporate network? Not necessarily. The app needs an approved path. Use [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud) when the app should run in your cloud account and use your existing private routes, or [Tailscale](https://northflank.com/docs/v1/application/network/use-tailscale) when selected workloads need an overlay path. ### Is a VPN enough to secure access to a private API? Not on its own. A VPN or a [Northflank Tailscale connection](https://northflank.com/docs/v1/application/network/use-tailscale) can supply private reachability, while workload authentication and API authorization decide what the caller can do. ### Can IP allowlisting replace workload identity? Not on its own. IP allowlisting restricts accepted source networks but does not authenticate a workload or establish application permissions. On Northflank’s managed cloud, selected services and jobs can use a [dedicated egress IP](https://northflank.com/docs/v1/application/network/configure-egress-ips) as the stable public source address for a firewall rule, while workload credentials and API policy provide identity and authorization. ### Should the frontend ever call the private API directly? Usually not for an internal company API. Put the call in a governed backend so API credentials, private routes, and authorization logic do not move into the browser. If Northflank runs that backend, [inject the private API credential](https://northflank.com/docs/v1/application/secure/inject-secrets) only into the service that makes the call. Expose only the backend endpoint the browser needs, and keep traffic to an internal gateway or service on a [private port](https://northflank.com/docs/v1/application/network/configure-ports#private-ports). ## Related articles about secure AI-built application infrastructure Use these guides for related security and deployment decisions. - [How do you connect vibe-coded apps to company data securely?](https://northflank.com/blog/connect-vibe-coded-apps-company-data-securely) - [How to deploy AI-built applications securely in your own cloud](https://northflank.com/blog/securely-deploy-ai-applications-in-your-cloud) - [How do you enforce data residency for AI-built applications?](https://northflank.com/blog/enforce-data-residency-ai-built-applications) - [How to build an enterprise platform for deploying AI-generated applications](https://northflank.com/blog/build-enterprise-ai-application-platform) - [How to isolate AI agents that have access to company data](https://northflank.com/blog/how-to-isolate-ai-agents-with-company-data)

Qwen3.8-27B: Performance, benchmarks, GPU requirements & how to run it

2026-08-17T23:00:00.000Z

# TL;DR Qwen3.8-27B is a 27-billion-parameter open-weight model from Alibaba's Qwen team that delivers strong coding, reasoning, multimodal, and agentic performance while remaining practical to self-host. For teams evaluating alternatives to closed models from OpenAI, Anthropic, or Google, the main advantage is the combination of capability and deployment size. Quantized versions of Qwen3.8-27B can run on a single GPU, including 24 GB configurations for lighter workloads, while larger GPUs provide more room for context, concurrency, and production throughput. Qwen3.8-27B is particularly well suited to coding agents, AI assistants, RAG, research tools, multimodal applications, and high-volume inference workloads where API costs can become significant. On Northflank, you can run Qwen3.8-27B with **SGLang**, expose it through an OpenAI-compatible API, choose the GPU that fits your workload, and run the model alongside the rest of your application without managing the underlying GPU infrastructure or Kubernetes yourself. **In short:** if you want a high-performance open model that is realistic to run on your own infrastructure, Qwen3.8-27B is one of the strongest options to test. Reach out to us and [book a demo with one of our engineers](https://cal.com/team/northflank/northflank-intro) to see how you can self-host Qwen3.8-27B. # Qwen3.8-27B: how good is it, and what do you need to run it? Qwen3.8-27B is a 27-billion-parameter open-weight model from Alibaba's Qwen team, designed for coding, reasoning, agents, multimodal applications, and other general-purpose AI workloads. The model has attracted attention for its combination of performance and size. Qwen3.8-27B performs competitively with much larger models across a number of coding and reasoning benchmarks, while remaining small enough to run on a single GPU with the right configuration. For developers, this makes Qwen3.8-27B an interesting model to test if you want strong performance without relying entirely on closed APIs or deploying a large multi-GPU cluster. You can deploy Qwen3.8-27B on Northflank using an inference engine such as SGLang, attach the GPU you need, expose an API endpoint, and run it alongside the rest of your application infrastructure. This article covers how Qwen3.8-27B performs, how it compares with closed models, what hardware it needs, and how to run it on Northflank. ## Is Qwen3.8-27B good? Yes. Qwen3.8-27B is a highly capable open-weight model for its size. The main reasons to consider it are: - **Strong performance for a 27B model.** Published benchmark results are competitive across coding, reasoning, and agentic tasks. - **Relatively small hardware footprint.** Quantized versions can run on a single GPU, including configurations with 24 GB of VRAM. - **Good fit for coding and agents.** Its performance on software engineering and terminal-based benchmarks makes it particularly relevant for coding agents and tool-using AI systems. - **Long context.** Qwen3.8-27B supports up to 262K tokens of context. - **Multimodal.** It can work with text and visual inputs. - **Open weights.** You can host it yourself, choose your GPU and inference engine, and keep inference within infrastructure you control. - **Efficient serving options.** Qwen3.8-27B can be served with runtimes including SGLang and vLLM. For teams that want to try Qwen3.8-27B without sourcing and managing GPU infrastructure themselves, you can run it on Northflank with SGLang and choose from available NVIDIA GPUs based on the performance and cost profile you need. ## What is Qwen3.8-27B? Qwen3.8-27B is a dense 27-billion-parameter open-weight AI model in Alibaba's Qwen family. It is a general-purpose model with support for coding, reasoning, tool use, visual inputs, long-context tasks, and agentic workflows. The 27B parameter count puts the model in a useful range for self-hosting. It is considerably smaller than many frontier-scale models, but its benchmark results suggest that the performance gap can be relatively narrow on some workloads. That makes Qwen3.8-27B relevant for developers who want to run their own models without giving up the level of capability required for production AI applications. Qwen3.8-27B can be used for applications including: - AI coding assistants - coding agents - general AI assistants - research agents - document analysis - multimodal applications - RAG - tool-calling agents - internal enterprise AI - high-volume inference workloads Because the weights are available, you can decide where and how inference runs rather than sending every request to a third-party model API. ## How good is Qwen3.8-27B? Qwen3.8-27B performs well for a model of its size, particularly on coding and reasoning tasks. Published results include: | Benchmark | Qwen3.8-27B | | --- | ---: | | Terminal-Bench 2.1 | 73.0 | | SWE-bench Pro | 61.7 | | GPQA Diamond | 89.2 | | NL2Repo | 42.3 | | DeepSWE | 42.2 | | Humanity's Last Exam | 30.8 | As with any model benchmark, these numbers need context. Different providers can use different reasoning settings, evaluation harnesses, tool configurations, and inference settings, so benchmark tables should not be treated as perfectly controlled head-to-head comparisons. They are still useful for understanding the general performance class of a model. For Qwen3.8-27B, the coding results are particularly relevant. Terminal-Bench and SWE-bench Pro evaluate tasks that are closer to real software engineering and agent workflows than simple coding questions. This makes Qwen3.8-27B worth testing if you're building a coding assistant or agent that needs to inspect repositories, reason about code, use tools, make changes, and iterate on results. ## How does Qwen3.8-27B compare with closed models? Qwen3.8-27B is competitive with closed models on a number of benchmarks, although it should not be treated as a universal replacement for the strongest models from OpenAI, Anthropic, or Google. Frontier proprietary models may still produce better results on the most difficult tasks. For teams deciding what to run in production, however, benchmark performance is only one part of the comparison. If Qwen3.8-27B performs well enough for your workload, you gain the ability to run the model on infrastructure you control rather than paying a model provider for every input and output token. | | Qwen3.8-27B | Closed model API | | --- | --- | --- | | Run it yourself | Yes | Usually no | | Choose your GPU | Yes | No | | Control where inference happens | Yes | Limited | | Open weights | Yes | No | | Optimize the serving stack | Yes | No | | Cost | GPU compute | Usually per token | | Setup | Requires deployment | API call | | Maximum performance | Very strong for its size | Frontier models generally lead | For an application making a relatively small number of requests, a closed API may be the easier choice. The economics become more interesting when inference volume increases. Coding agents are a good example. A single task might cause an agent to repeatedly read files, generate code, execute commands, inspect results, and ask the model what to do next. A single user action can therefore generate a large amount of inference. If Qwen3.8-27B can handle those requests effectively, running the model on your own GPU gives you a different cost model. Instead of paying for each token, you pay for the GPU capacity used to serve the model. ## Qwen3.8-27B can run on relatively small GPUs Running an open model becomes significantly more expensive when it requires several high-end GPUs just to load the model. Qwen3.8-27B has 27 billion parameters, which gives teams considerably more flexibility in how they deploy it. At full precision, the model still requires substantial GPU memory. Quantization can reduce its memory footprint considerably, making single-GPU deployments possible. A rough guide looks like this: | GPU memory | Qwen3.8-27B use | | --- | --- | | 24 GB | Quantized inference, testing, lower concurrency | | 32 to 48 GB | More headroom for production inference | | 80 GB | Higher precision, longer context and greater concurrency | | 140 GB+ | Large context and high-throughput serving | The exact requirement depends on how you configure the model, particularly the quantization level and context window. For many workloads, you do not need a large multi-GPU cluster simply to start serving Qwen3.8-27B. This makes the model much more accessible for teams that want to experiment with running their own inference. ## Can Qwen3.8-27B run on a 24 GB GPU? Yes, with quantization. Quantization reduces the amount of memory required to store and run a model. A 4-bit version of a 27B model requires considerably less memory than the original higher-precision weights. Early Qwen3.8-27B quantizations have brought the model weights into roughly the 14 to 17 GB range. That makes deployment on a 24 GB GPU possible. There are tradeoffs. GPU memory is also needed for the context window, concurrent requests, and the inference runtime, so fitting the model weights onto a 24 GB GPU does not mean every workload will run comfortably on 24 GB. For experimentation and smaller workloads, however, the ability to run a model with this level of performance on a single 24 GB GPU is useful. You can start with relatively modest hardware and move to a larger GPU when you need more throughput, context, or concurrency. ## Is Qwen3.8-27B fast? Qwen3.8-27B can deliver fast inference, particularly when paired with an optimized inference engine and suitable GPU. There is no single representative tokens-per-second number because performance varies significantly based on the GPU, quantization, prompt size, context length, batching, and inference runtime. Early tests have shown Qwen3.8-27B generating at interactive speeds on single-GPU configurations. The model also supports multi-token prediction, which compatible inference engines can use to improve generation performance. For most teams evaluating Qwen3.8-27B, the important question is whether the model can meet the latency and throughput requirements of the application at an acceptable GPU cost. That is best answered by running the model against your own workload. ## Qwen3.8-27B is particularly interesting for AI agents Agent workloads can consume a lot of inference. A traditional chatbot might receive a prompt and generate one response. An agent may call a model repeatedly while completing a task. For example, a coding agent could inspect a repository, read relevant files, determine what needs to change, generate code, run the code, inspect errors, modify its solution, run tests again, and produce the final result. Each stage can involve additional inference requests. This makes the performance-to-cost ratio of the underlying model important. A smaller model that performs well on coding and tool-use tasks can be useful because it allows teams to run significant amounts of inference without necessarily requiring very large GPU infrastructure. Qwen3.8-27B's combination of coding performance and relatively modest hardware requirements makes it a strong candidate for this type of workload. ## Why run Qwen3.8-27B yourself? Using an API from OpenAI, Anthropic, Google, or another model provider remains the easiest way to add a powerful model to an application. Self-hosting becomes more attractive when you care about control, cost at scale, or where inference happens. With Qwen3.8-27B, you control: - the GPU - the inference engine - the model configuration - where the workload runs - how it scales - access to the model endpoint - the surrounding application infrastructure For high-volume applications, running your own inference can also make costs easier to reason about. Your primary cost becomes the infrastructure running the model rather than a bill that grows directly with every token processed. Whether that is cheaper depends on utilization. A GPU sitting idle is not cost-efficient. A well-utilized GPU serving a large volume of requests can be. ## Running Qwen3.8-27B with SGLang Qwen3.8-27B can be served using inference engines including SGLang and vLLM. We run Qwen3.8-27B with **SGLang on Northflank**. SGLang is an open-source serving framework for high-performance LLM and multimodal inference. It provides the serving layer between the model and your application, handling requests and efficiently using the underlying GPU. SGLang also exposes an OpenAI-compatible API. If your application already works with an OpenAI-compatible endpoint, you can point it at a Qwen3.8-27B deployment without having to redesign your application around a completely different model interface. vLLM is another option for serving Qwen models. Northflank supports containerized GPU workloads generally, so you can choose the inference framework that fits your application. For Qwen3.8-27B, we use SGLang because it provides a high-performance serving path for the model and works well with the GPU infrastructure available on Northflank. ## Run Qwen3.8-27B on Northflank You can run Qwen3.8-27B on Northflank without managing the underlying GPU servers or Kubernetes infrastructure yourself. Northflank lets you deploy Qwen3.8-27B with SGLang as a GPU-backed service, expose it as an inference API, monitor it, scale it, and connect it to the rest of your application. You choose the GPU based on the performance and cost profile you need. That flexibility is useful for a model like Qwen3.8-27B because the model can run across a relatively broad range of hardware. You can use a smaller GPU for experimentation or lower-volume inference and move to higher-memory, higher-performance GPUs when you need more throughput or concurrency. Northflank also runs the rest of the application alongside the model. This becomes useful when moving from a model demo to a production AI application. Most production systems need more than an inference endpoint. They also need application services, databases, workers, storage, networking, secrets, logs, metrics, and deployment pipelines. Northflank provides those components alongside GPU workloads, so the model does not need to live in a separate infrastructure stack. You can run the deployment on Northflank's managed cloud or deploy Northflank into your own cloud environment using BYOC. ## Which GPU should you use for Qwen3.8-27B? There is no reason to automatically start with the largest GPU available. The right GPU depends on how you intend to use Qwen3.8-27B. If you are experimenting with the model or serving relatively low traffic, a smaller GPU and quantized version of Qwen3.8-27B may be enough. If you need longer context windows or more simultaneous requests, additional GPU memory becomes useful. If you are serving significant production traffic, a more powerful GPU may cost more per hour but provide better overall economics because it can process substantially more inference during that hour. The practical approach is to benchmark the model on the workload you actually plan to run. Start with a configuration that fits Qwen3.8-27B comfortably, measure latency and throughput, and adjust the GPU based on real utilization. Northflank gives you access to GPU infrastructure without requiring you to build the orchestration layer around it, making it easier to test different hardware configurations for Qwen3.8-27B. ## Qwen3.8-27B vs using an API: which should you choose? Use a closed API if you want the simplest possible integration and need access to the strongest proprietary model available. Consider running Qwen3.8-27B if you want strong model performance while having more control over infrastructure and inference costs. Qwen3.8-27B becomes particularly attractive when: - you are making a large number of inference requests - you are building AI agents - you are building coding tools - you want to run inference privately - you want control over the GPU and serving stack - you want predictable infrastructure-based costs - you want to avoid relying on a single proprietary model provider You can also use both. For example, an agent could use Qwen3.8-27B for tasks it handles reliably and route particularly difficult requests to a larger proprietary model. This can reduce the amount of frontier-model inference required while retaining access to those models when they provide a meaningful improvement. ## Is Qwen3.8-27B worth trying? If you are evaluating open models in 2026, Qwen3.8-27B should be on the shortlist. It combines strong coding, reasoning, multimodal, and agentic capabilities with hardware requirements that make self-hosting practical. Quantized versions can run on a single GPU, while larger GPUs provide additional capacity for context, concurrency, and production throughput. This makes Qwen3.8-27B relatively straightforward to evaluate against the models you already use. Run the same prompts through Qwen3.8-27B and your existing model API. Compare output quality, latency, throughput, and cost using your actual workload rather than relying entirely on public benchmarks. If Qwen3.8-27B performs well enough for your application, you have the option to run inference on infrastructure you control and choose the GPU configuration that makes sense for your traffic. You can deploy **Qwen3.8-27B with SGLang on Northflank**, choose the GPU resources you need, and run the model alongside the rest of your application without managing the underlying Kubernetes and GPU infrastructure yourself. [Deploy Qwen3.8-27B on Northflank](https://northflank.com)

The future of the AI-native internal developer platform & the AI SDLC

2026-08-14T19:00:00.000Z

For the last decade, the internal developer platform was designed around a relatively stable assumption: software is written by engineers, in quantities that humans can reasonably review, deploy and operate. That assumption is disappearing. Coding agents are making software dramatically cheaper to produce. Soon, the limiting factor inside large organizations will not be how quickly they can write code. It will be whether they can safely turn an enormous and continuously growing volume of code into running software. This changes the role of the internal developer platform. The next generation of developer infrastructure will need to assume that code is abundant, increasingly autonomous and untrusted by default. It will need to give developers and agents the same path from commit to production, without giving up the security, governance and infrastructure control that enterprises require. We think this will become one of the most important layers of the AI-native enterprise. ## Code generation is becoming the easy part An extraordinary amount of investment has gone into making software easier to write. The results are already visible. Coding agents can generate features, fix bugs, create entire applications and allow people who previously did not write software to produce it. But generating code is one step in a much longer software lifecycle. ![Group 1.png](https://assets.northflank.com/Group_1_ccfea28659.png) The code still needs to be built. Tested. Given infrastructure. Connected to databases and other services. Run in realistic preview environments. Observed. Secured. Deployed. Scaled. Updated. Eventually retired. And inside an enterprise, all of this has to happen within existing security, networking, compliance and infrastructure boundaries. The faster code generation becomes, the more important everything after code generation becomes. We are beginning to see this directly. Northflank is receiving more enterprise inbound than at any point in our history, much of it from sophisticated engineering organizations arriving with remarkably similar requirements. They are adopting coding agents, generating far more software, and realizing that their existing internal platforms were never designed for this level of throughput. Increasingly, the conversation starts with a simple question: **How do we safely deploy all of this?** ## The internal developer platform becomes a system of action There has always been some ambiguity around the term "internal developer platform." Many IDPs are effectively **portals**: systems of record that provide a catalog and UI over internal systems, Terraform modules and third-party services. They help developers discover infrastructure, but they do not themselves deploy and run workloads in production. The actual platform underneath has historically been built by the enterprise. Platform teams have assembled Kubernetes, Terraform, CI/CD, observability, networking and other tools into bespoke internal platforms. This gives organizations control, but leaves them responsible for building the abstractions, maintaining the integrations and evolving the entire system as requirements change. ![CleanShot 2026-08-14 at 22.38.11@2x.png](https://assets.northflank.com/Clean_Shot_2026_08_14_at_22_38_11_2x_960ef8f2d6.png) AI changes the requirement. A platform designed for agents cannot merely describe how software should be deployed. It needs to actually deploy it. An agent should be able to produce code and hand it to a platform with a well-defined contract: build this, provision what it needs, isolate it, deploy it, expose it, observe it and enforce the policies of the organization. The developer platform becomes a **system of action** for software. This is the abstraction we have spent years building at Northflank. A service, database, job, GPU workload, preview environment or production deployment can all be expressed through the same platform primitives. Humans can use those primitives through an interface. Agents can use them programmatically. The underlying infrastructure can change without changing that contract. As the volume of software grows, that abstraction becomes increasingly important. ## All code should be treated as untrusted AI also forces a change in the enterprise security model. Historically, infrastructure was built around a loose assumption that application code came from trusted engineers inside the organization. That assumption was already questionable. Software depends on enormous dependency trees, third-party packages and external systems. With generated code, it becomes untenable. If an agent can generate and modify software autonomously, the infrastructure executing that software should assume that the workload may be compromised. This is why we think sandboxing, while important, is ultimately a platform primitive rather than a standalone category. On Northflank, workloads can run inside microVMs by default. That isolation model should apply whether the workload is an ephemeral agent sandbox, a preview environment, a cron job, a database or a production service. The interesting question then becomes: **How do I build an enterprise software platform where isolation is a property of every workload?** Sandboxing is one piece of that architecture. The platform around it is the much larger opportunity. ## Kubernetes matters more in the AI era, not less There is a temptation whenever a new computing paradigm emerges to assume that the infrastructure underneath it will disappear. We believe the opposite is happening. Large enterprises have spent the last decade standardizing around Kubernetes. Their networking, security, observability, infrastructure teams and operational practices are built around it. AI does not erase those requirements. If anything, it makes them more important. The overwhelming pattern we see from enterprises evaluating Northflank is a requirement to run inside their own cloud environment. They want the developer experience of a modern PaaS, but they need workloads inside their AWS, GCP or Azure VPC, private cloud or on-premises infrastructure. They need their network boundaries, their compute, data, policies, and now, their own choice of harness. This is one reason we made the decision very early to build Northflank on Kubernetes. The winning enterprise platform cannot require companies to abandon the infrastructure they have spent a decade adopting. It needs to provide a much better abstraction over it. The developer should not need to care where every workload runs. The enterprise absolutely will. ## What the AI-native enterprise platform requires We believe a few architectural properties become non-negotiable in the AI-native enterprise. **The control plane and runtime need to be separable.** The platform that orchestrates software should not dictate where that software runs. At Northflank, the control plane manages the developer experience, deployments and infrastructure lifecycle, while runtimes can live across Northflank infrastructure, an organization's own cloud accounts, private infrastructure or other compute providers. This makes **bring your own cloud (BYOC)** fundamental. Enterprises increasingly need to place workloads according to security requirements, data residency, economics and compute availability. As AI infrastructure fragments across hyperscalers, private clouds, neo-clouds and specialized GPU providers, that flexibility becomes even more valuable. For the most security-sensitive organizations, separating control plane and runtime is still not enough. The control plane itself needs to be capable of running inside the organization's environment. Northflank can be **fully forward deployed**, keeping both the platform control plane and its workloads within the customer's infrastructure and security boundary. This matters for governments, regulated industries and large enterprises, which are already running workloads on Northflank. Finally, **workload isolation needs to be built into the runtime itself.** Northflank can run workloads inside microVM-based sandboxes, combining VM-level isolation with the orchestration and developer experience of Kubernetes. Sandboxing is therefore not a separate destination for a special class of AI workload. It is an infrastructure primitive that can extend from ephemeral agent execution and preview environments through to long-running production workloads. The AI-native enterprise platform, in our view, needs all four: **a Kubernetes foundation, portable runtimes, a forward-deployable control plane and microVM-based workload isolation.** Without those properties, you can build an excellent developer tool. It is much harder to become the platform through which a large enterprise runs its software. ## Northflank, as the runtime platform for the AI-native enterprise to complete its AI SDLC ![CleanShot 2026-08-14 at 22.38.18@2x.png](https://assets.northflank.com/Clean_Shot_2026_08_14_at_22_38_18_2x_abc2fa6bab.png) We started Northflank with a fairly simple belief: developers should be able to deploy complex workloads without becoming infrastructure experts, while enterprises should retain control of the infrastructure those workloads run on. For a long time, that was mostly a developer experience argument. The more software an organization produces, the more important the infrastructure underneath it becomes. That infrastructure has to assume code is untrusted, support a much larger number of workloads without creating more operational overhead, and give enterprises flexibility over where those workloads run. And it has to do all of this within the security and infrastructure boundaries enterprises already have. Coding agents will move from a developer’s laptop to remote, secure environments because a coding harness running on a developer’s laptops is essentially a root kit and anything the developer’s laptop can access, the harness can access, too. Folks will be having more parallel coding sessions with multiple streams of work, so there will undoubtedly not be enough compute on a laptop. With Northflank, a coding harness can run in a secure remote environment, generate code, build it and deploy it into a production-like preview environment where developers can see how it actually behaves. This matters because AI can review its own code, but that is still the model marking its own homework. The application needs to run. From there, the same platform carries the workload through testing, staging and production, with the same primitives for compute, databases, networking, observability, scaling and microVM isolation throughout. That is what we believe the AI-native internal developer platform becomes: **the execution layer between an increasingly autonomous software development process and the infrastructure of the enterprise.** Humans or agents can write the code. AWS, GCP, Azure, private cloud, neo-clouds can provide the compute. Kubernetes can remain the substrate. The developer platform is the layer that makes all of it usable as one coherent system. We have been building toward that architecture for years. What has changed is that the enterprise now appears to be arriving at the same conclusion. If you're contemplating how your enterprise can run AI-generated code securely, [let's chat](https://cal.com/team/northflank/northflank-intro).

How do you enforce data residency for AI-built applications?

2026-08-14T16:15:00.000Z

An AI-built application may run in an approved region while sending prompts elsewhere, copying logs to a global service, or restoring backups across borders. Region selection is one part of data residency. Enforcing residency requires an end-to-end boundary. This guide covers AI data flows, policy, regional architecture, egress, BYOC, verification, and Northflank workload-placement controls. ## TL;DR: How to enforce data residency for AI-built applications Enforce data residency by attaching a machine-readable location policy to each tenant, dataset, and workload, then using it to control placement, routing, egress, replication, backup, and operational access. - Inventory relevant data categories, including prompts, retrieval context, embeddings, logs, backups, build artifacts, and support exports. - Assign approved storage and processing locations when the tenant or dataset is created. Reject an operation when no compliant destination is available. - Keep the regional data plane complete and block silent fallback to another region. - Treat model APIs, telemetry, analytics, and support systems as data destinations, even when the main database stays local. - Test the boundary continuously and retain evidence of where workloads, storage, network traffic, replicas, and backups actually reside. If your enterprise needs approved account, VPC, and regional placement without direct builder access to infrastructure, [Northflank](https://northflank.com/) provides a governed deployment layer. Use [Northflank Cloud](https://northflank.com/cloud/northflank) where its regions fit your policy, or self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud) for workload runtime and data in your cloud. Assess metadata, logs, builds, images, DNS, and backups separately. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## What does data residency mean for AI-built applications? For this guide, a data-residency policy defines where specified application and AI data may be stored and, where required, processed. It is distinct from sovereignty, security, privacy, and compliance. Keeping a database in one country does not prove lawful processing, suitable retention, adequate access controls, or the absence of restricted transfers through connected services. Infrastructure location does not determine whether an international transfer of personal data is lawful. Confirm applicable jurisdictions, data categories, recipients, and requirements with privacy and legal teams. ## Which AI application data flows must stay inside the residency boundary? The residency boundary should cover AI application records, prompts, derived data, operational data, and administrative paths. A database-only inventory can miss several flows, particularly when applications [connect to company data](https://northflank.com/blog/connect-vibe-coded-apps-company-data-securely). | Data category | Where it can move | Control to verify | | --- | --- | --- | | User records and uploads | Application, database, object storage, cache | Workload and storage region, replication policy | | Prompts and retrieval context | Model, moderation, search, or tool endpoint | Endpoint region, payload policy, provider terms | | Embeddings and agent memory | Vector store, cache, database, evaluation system | Storage and processing region, retention | | Logs, traces, and analytics | Platform logs, log sink, APM, analytics service | Redaction, destination, access, retention | | Backups and replicas | Secondary region, object store, disaster-recovery account | Backup destination and restore policy | | Builds and artifacts | CI workers, registry, build logs, test environment | Build location and artifact contents | | Control-plane and support data | Deployment platform, ticketing, support export | Metadata scope, administrator access, subprocessors | ## How do you turn AI application data residency into an enforceable policy? Turn an AI application's data-residency requirement into an enforceable policy by defining the covered data, permitted storage and processing locations, approved services and recipients, and allowed backup, replication, and failover destinations. A requirement such as “keep EU customer data in Europe” is too broad to enforce without these details. Create a policy for each protected data category. Define: - the tenants, datasets, or workloads covered by the policy - permitted locations for storage and processing - approved services, recipients, and subprocessors - permitted replication, backup, failover, and support paths - retention, deletion, encryption, and key-management requirements Assign the applicable policy when a tenant or dataset is created. Changing its residency location should require a controlled migration rather than an IP-based assumption or an unrestricted region choice. Enforce the policy by default. If a model endpoint, cluster, database, backup destination, or failover target is not permitted, reject the operation instead of silently routing data elsewhere. ## What architecture enforces data residency for AI-built applications? A practical AI application architecture applies one location decision across ingress, compute, storage, egress, and operations. These seven controls are a reference framework. ### 1. Assign a residency attribute at creation Give each tenant, dataset, and workload an authoritative residency attribute before accepting protected data. Propagate it with jobs, events, files, and records so asynchronous workers follow the same policy. A tenant-to-region registry creates one source of truth. If your platform team needs to bind tenants or environments to approved infrastructure, it can [create each Northflank project on a specific BYOC cluster](https://northflank.com/docs/v1/application/bring-your-own-cloud/deploy-workloads-to-your-cluster), turning the residency decision into a reusable placement boundary. ### 2. Route before processing Resolve the policy before processing, then keep jobs, events, and callbacks in the permitted boundary. Reject mismatched requests and disallowed cross-region retries. If services, jobs, and databases should communicate without public endpoints, Northflank [private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank#private-networking) keeps those paths private within the cluster. ### 3. Keep the regional data plane complete Run the API, workers, database, vector store, objects, cache, queue, keys, and regional telemetry in allowed locations. If the regional boundary must include compute and data services, Northflank runs [stateful workloads](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank) beside AI application services and workers under the same deployment path. Make replication explicit. If a residency policy restricts where database copies may be stored, place replicas only in approved locations. Apply the same restriction to object versions, snapshots, indexes, and caches. ### 4. Constrain model and service egress Treat external model and tool calls as potential data transfers. The application region does not determine where a provider processes prompts, context, files, or tool results. Allowlist model endpoints and connected services by residency class. Minimise payloads and disable unapproved failover. Review embedding, moderation, search, analytics, and error-tracking services too. If deny-by-default egress is required, configure Northflank [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies) with explicit outbound rules. When no egress rules exist, outbound traffic is allowed. Application policy still decides which records an approved destination may receive. ### 5. Enforce placement through the platform Developers and coding agents should use approved Northflank [templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code) for repeatable project resources and deployments. Assign projects to approved clusters, and configure registries, backups, and network policies at their respective scopes. Use [Northflank Environments](https://northflank.com/docs/v1/application/getting-started/set-up-environments) to organize release workflows across development, staging, and production. Reject workloads that reference disallowed clusters or endpoints. Scope identities to reduce template bypass, and record deployment and network changes. Build location needs its own policy. A project running on BYOC does not mean its builds automatically run there; [configure the cluster's build infrastructure](https://northflank.com/docs/v1/application/bring-your-own-cloud/configure-your-cluster) to build on the same or another approved cluster when source, build logs, or images must remain in that boundary. ### 6. Separate operations and disaster recovery Operations create separate data paths through global logs, support exports, central backup buckets, and disaster-recovery targets. Approve destinations, redact logs, restrict support access, and limit failover. Northflank [global backups](https://northflank.com/docs/v1/application/databases-and-persistence/global-backup) can use customer-controlled S3-compatible storage on BYOC. Restrict restore targets separately because global backups support cross-project and cross-region restoration. ### 7. Detect drift and prove the boundary Use preventive controls to reject disallowed placement, destinations, backups, and failover before data moves. Use detective controls to identify later drift across regions, storage, replicas, log sinks, endpoints, and traffic. Monitoring alone does not enforce residency. Record policy decisions and rejected application operations in the relevant application, network, and cloud logs. If auditors need infrastructure-change evidence, Northflank [platform audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) show platform events, affected resources, and configuration differences. ## Is BYOC enough to enforce data residency for AI-built applications? Not on its own. [BYOC can place an AI-built application's workload data plane](https://northflank.com/blog/what-is-byoc-in-cloud-computing) inside your account, VPC, and selected region, but it does not by itself constrain connected services or additional platform data. BYOC gives your enterprise control over the cloud account, region, network, and underlying infrastructure, and can integrate with customer-controlled storage, identities, and key-management services. You still need to assess model APIs, log sinks, registries, CI systems, DNS, backups, support access, and control-plane metadata. Ask each platform for a data-flow diagram and a location statement for each relevant data category. A claim that the platform “runs in your cloud” does not, by itself, establish where each category is stored or processed. ## How can Northflank help enforce data residency for AI-built applications? Northflank helps enforce the infrastructure part of data residency by placing projects and their workloads on approved clusters and applying access, networking, release, backup, and audit controls around them. If your enterprise needs workload runtime and data in its own cloud account, [Northflank BYOC](https://northflank.com/cloud) provisions and manages clusters in Google Cloud Platform, AWS, Microsoft Azure, Civo, Oracle Cloud Infrastructure, CoreWeave, or Nebius accounts. If you already operate Kubernetes on private infrastructure, [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements) lets your team import suitable existing Kubernetes clusters, including clusters running [on-premises or on bare-metal infrastructure](https://northflank.com/features/bring-your-own-cloud). See the Northflank controls that support this infrastructure boundary: - **Project-level placement:** [Assign a project to a specific BYOC cluster](https://northflank.com/docs/v1/application/bring-your-own-cloud/deploy-workloads-to-your-cluster) so its services, jobs, databases, and volumes run on the infrastructure target your team has approved. - **Private networking:** Use [private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank#private-networking) to keep internal service paths off public endpoints where appropriate for your architecture. - **Access control:** Use [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [SAML or OIDC SSO](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation), [MFA enforcement](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication#multi-factor-authentication), and [scoped API roles](https://northflank.com/docs/v1/application/secure/grant-api-access) to restrict which people and automations can change your stack. - **Auditability and operations:** Use [platform audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) to review infrastructure changes, while workload logs and metrics help your operations team monitor the applications running there. - **Reviewable external destinations:** Configure [external log sinks](https://northflank.com/docs/v1/application/observe/configure-log-sinks) and [backup destinations](https://northflank.com/docs/v1/application/databases-and-persistence/global-backup#global-backup-destinations) explicitly so your security and privacy teams can assess them against the residency policy. - **Data-boundary visibility:** Review how Northflank distinguishes BYOC workload data from hosted control-plane metadata, and assess the separate location options for builds, logs, DNS, and backups in the [Northflank security details](https://northflank.com/security). - **AI-agent access:** Use [Northflank Skills](https://github.com/northflank/skills) to help AI coding agents operate the platform through the access your team assigns to them. - **Compliance support:** Northflank is [SOC 2 Type 2 compliant and HIPAA compliant](https://northflank.com/security), with Business Associate Agreements supported under Enterprise contracts. These controls can support the security and governance requirements within your broader compliance program. > [Upwork's Lifted runs its developer platform with Northflank BYOC inside its AWS VPC](https://northflank.com/blog/upwork-lifted-runs-production-workloads-inside-their-own-vpc-with-northflank). Its security team retains control and audit visibility while application engineers deploy through self-service. > [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## What should you test to verify AI application data residency? Test AI application residency controls from creation through failure and deletion because a configuration review may not expose fallback paths. - Create a tenant for each residency class and confirm its resources land in approved targets. - Send a request through the wrong regional endpoint and confirm it fails before protected data is processed. - Disable the preferred model or region and confirm the application does not use an unapproved fallback. - Inspect outbound traffic and verify that model, telemetry, analytics, and tool destinations match the allowlist. - Trigger database, object, and configuration backups and verify their destination and restore target. - Export logs or a support bundle and check it for protected content and destination scope. - Attempt an unauthorized region or log-sink change and confirm policy and role controls reject it. - Delete a test subject and verify the expected behavior across primary, replica, cache, vector, and backup systems. Run these tests in delivery pipelines and repeat inventory checks in production. Re-evaluate the boundary when adding a provider, model, region, support process, or data category. For automated infrastructure tests, use the Northflank API to check project placement, [templates and GitOps](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code) to repeat configuration, and [workflows](https://northflank.com/docs/v1/application/release/configure-workflows) to run jobs, backups, conditions, and approvals. [Metrics](https://northflank.com/docs/v1/application/observe/view-metrics) show traffic levels; [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) show platform changes. Destination evidence may require cloud flow or DNS logs, firewall telemetry, or a proxy. Test application routing, fallback, deletion, and external providers separately. ## Frequently asked questions about data residency for AI-built applications These answers distinguish infrastructure location from wider privacy and transfer requirements. ### Does deploying in an EU region make an AI-built application GDPR compliant? Not on its own. Regional deployment can support a GDPR strategy, but compliance also depends on lawful processing, retention, security, individual rights, processor governance, and transfer rules. [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud) can run application workloads and their data plane on a cluster deployed in your selected EU cloud region, but privacy and legal teams must assess the complete data flow. ### Can an AI application use a model API outside its deployment region? Technically yes, but the call may break the residency policy or create an international transfer. Evaluate the payload and provider first. Where required, Northflank can run application services and [GPU-backed model workloads](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud) in a customer-controlled BYOC cluster. ### Do backups and logs count toward data residency? They can. Backups and logs may contain records, identifiers, prompts, or outputs. Northflank's [security details](https://northflank.com/security) distinguish volume snapshots stored in BYOC, database dumps stored in Northflank S3, and logs and metrics hosted by Northflank or in BYOC infrastructure. [Global backups](https://northflank.com/docs/v1/application/databases-and-persistence/global-backup#global-backup-destinations) can use customer-controlled S3-compatible destinations. Review storage and restore targets separately because global backups support cross-region restoration. ### Should each region have a separate application stack? Often, when the policy requires strict separation. [Northflank projects can be assigned to regional BYOC clusters](https://northflank.com/docs/v1/application/bring-your-own-cloud/deploy-workloads-to-your-cluster), giving each AI application stack a clear placement boundary. Across any platform, shared services used by those regional stacks must also meet the applicable residency policies. ## Related articles about secure AI-built application infrastructure - [How to deploy AI-built applications securely in your own cloud](https://northflank.com/blog/securely-deploy-ai-applications-in-your-cloud) - [How do you connect vibe-coded apps to company data securely?](https://northflank.com/blog/connect-vibe-coded-apps-company-data-securely) - [How enterprises should govern AI-built applications at scale](https://northflank.com/blog/how-enterprises-should-govern-ai-built-applications-at-scale) - [What is BYOC in cloud computing?](https://northflank.com/blog/what-is-byoc-in-cloud-computing) - [Where should you deploy your AI-built apps?](https://northflank.com/blog/where-to-deploy-ai-built-apps)

How do you connect vibe-coded apps to company data securely?

2026-08-14T16:14:00.000Z

A vibe-coded app is built primarily through natural-language instructions to an AI coding tool, often with limited manual implementation. It can look ready after displaying records, but connecting it to company data creates a security boundary. Here, company data includes internal databases, private APIs, documents, customer records, analytics, and operational systems. The safe approach controls the request path from the user, through the application, to the data source. This guide covers identity, authorization, credentials, private networking, environment separation, testing, auditability, and incident response. ## TL;DR: How to connect vibe-coded apps to company data securely Put a controlled data-access layer between the vibe-coded application and company systems, then enforce identity, least privilege, private connectivity, secret management, and auditability across the path. - Inventory the records, fields, and operations the application requires. - Preserve user identity and give the backend a separate workload identity. - Authorize each action and object at a trusted server-side boundary. - Use restricted networking and narrowly scoped runtime credentials. - Separate non-production access, test denied paths, and prepare fast revocation. If your platform team needs an approved destination for AI-built applications, [Northflank](https://northflank.com/) can run the application beside private services and databases, inject runtime secrets, and apply platform access controls without giving every builder direct cloud-console access. Use [Northflank Cloud](https://northflank.com/cloud/northflank) for managed infrastructure or deploy with self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud) when the workload needs private reachability to systems in your cloud account, regional placement, or customer-controlled infrastructure. Your application and data systems still enforce which records each user may access. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## Why is connecting a vibe-coded app directly to production data risky? Connecting a vibe-coded app directly to production data is risky because a working interface does not prove that identity, authorization, credentials, and data boundaries are enforced. Generated code may authenticate a user but fail to check whether that user owns the record in the URL. It may use one database account for every table, return unnecessary fields, or place a server credential in code delivered to the browser. If an endpoint accepts a customer, invoice, or document ID, the server must check that the signed-in user can perform the requested action on that specific object. Hiding the link in the interface or using an unpredictable ID is not an authorization decision. A broad backend credential makes the database see every user as the application, so one route can inherit its full blast radius. ## What should a secure data-access architecture for vibe-coded apps look like? A vibe-coded app's secure data path can be designed as seven controls. This practical reference architecture can be adapted to your systems. ### 1. Classify the data and operations Start with what the application must do, not with the connection string it could use. Identify the source systems, records, fields, users, environments, and retention requirements. Separate reads from writes and individual lookups from bulk exports. Then reduce the surface. A support tool that displays an account name and open tickets does not need payment details or access to the entire customer table. This inventory becomes a concrete access contract for security and data owners to review. ### 2. Put a trusted interface in front of production data Expose the smallest useful data surface. For sensitive or shared systems, that will often be a purpose-built API, gateway, database view, stored procedure, or brokered query service rather than a general production database account. If your trusted API and database need one deployment model, a Northflank [deployment service](https://northflank.com/docs/v1/application/run/run-an-image-continuously) can run beside [stateful workloads](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank). The service can use a restricted database identity with carefully designed views or row policies. ### 3. Carry user and workload identity separately Authenticate the person using the application through your enterprise identity provider. If your teams need governed platform access, Northflank supports [SAML or OIDC SSO and MFA enforcement](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation#configure-single-sign-on-sso). The backend still needs its own workload identity or service credential. Keep those identities distinct. The workload identity answers “which application made this request?” The user identity answers “on whose behalf, and with what business authority?” Do not grant access based only on network location. Evaluate user, application, and service identities in the access policy. ### 4. Authorize every action and object Make authorization a server-side decision for each request. Evaluate the operation, resource, object, fields, environment, and relevant attributes such as tenant, ownership, department, or purpose. Apply least privilege, deny access by default, and validate permissions on every request. If builders need different levels of platform access, Northflank [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control) can restrict who changes projects, services, and secrets. Your application still enforces access to business records. Keep policy close to the trusted data boundary. Browser checks improve the interface, but users control the browser. Database policies can add another layer where they support the required identity model. ### 5. Inject narrowly scoped credentials at runtime Do not place company credentials in a prompt, generated source file, repository, container build argument, or browser bundle. Treat anything sent to the browser as accessible to the user. Store credentials in an approved secrets manager and provide them only to the backend workload that needs them. Prefer short-lived tokens or dynamic database credentials. Otherwise, create a separate credential for each application and environment, scope it, rotate it, and make it easy to revoke. If several services or jobs need the same runtime configuration, Northflank [secret groups](https://northflank.com/docs/v1/application/secure/manage-secret-groups) let selected workloads inherit it without putting values in generated code. Keep each group scoped to the application and environment, and redact secrets from logs. ### 6. Restrict the network path Keep internal databases and APIs off the public internet when the architecture allows it. Run the application in a network that can reach the required service privately, or create a tightly controlled route through a gateway, VPN, private link, or equivalent connector. Restrict outbound access when the application has no reason to contact arbitrary destinations. If the app, API, and database should communicate without public ports, Northflank [private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank#private-networking) connects them inside a project. Multi-project networking and Tailscale can extend that path when systems sit elsewhere. Private reachability still requires identity and per-request authorization. ### 7. Record decisions and bound data movement Create an application-level trail that records the authenticated user, workload identity, operation, target resource, policy result, outcome, and correlation ID. Log sensitive request or response content only when policy permits it, and do not log secrets. Add query, response-size, rate, and timeout limits appropriate to the use case. A customer lookup tool should not become an unrestricted export interface because a generated endpoint accepts a large page size. If an investigation needs infrastructure evidence, [Northflank audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) can identify platform changes, the actor, and the affected resource. The application or data gateway should record which business records were requested or changed. Correlate both. ## Should a vibe-coded app connect directly to a database or use an API? It depends on the workload, but a purpose-built API is usually the clearest default for multiple users or sensitive records. Use the pattern that exposes the smallest stable interface and enforces authorization consistently. | Connection pattern | Best fit | Main control requirement | | --- | --- | --- | | Purpose-built API | Shared rules, multiple clients, or sensitive production data | Central object and action authorization | | Restricted database identity | A narrow internal workload with a stable schema | Database permissions, views or policies, and strict credential scope | | Read replica or curated dataset | Analytics and read-heavy applications | Freshness controls, field minimization, and read-only access | | Event or job interface | Asynchronous changes to company systems | Schema validation, idempotency, and bounded consumers | A restricted database connection can suit one narrow backend operation. A replica protects the write path but still needs access and retention rules. ## How should AI-built apps separate development and production data access? AI-built apps should not inherit production identity or data access in non-production. Give development, previews, staging, and production separate credentials, scopes, and data resources where practical. Use synthetic, masked, or minimized datasets for routine development. Treat necessary production-data testing as a controlled exception with a named owner, limited purpose, restricted environment, and expiry. Promote reviewed code and configuration into production instead of copying a builder's local credentials. Northflank [preview blueprints](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) can create an isolated copy of the application stack, while [environments](https://northflank.com/docs/v1/application/getting-started/set-up-environments) and workflows provide a controlled route to production. This applies the same release principle used when [moving an AI agent from sandbox to production](https://northflank.com/blog/how-to-deploy-ai-agent-from-sandbox-to-production). ## How do you test and operate a vibe-coded app's data connection safely? Test the vibe-coded app's denied paths and operational controls, not only whether an authorized user can load the expected screen. - Request the route anonymously and with an expired session. - Use a valid user who lacks permission for the function. - Change object identifiers to records owned by another user, tenant, or department. - Request restricted fields and attempt writes through read-only routes. - Send bulk requests, extreme page sizes, malformed inputs, and repeated calls. - Revoke the workload credential and confirm that access stops without exposing it in logs. - Fail the identity provider, policy service, and data source, then confirm that the application denies safely. Automated scans can find important defects, but they do not prove that business authorization is correct. Add unit and integration tests for those rules and run them against the application, identity, policy, and data layers together. In production, alert on unusual denied requests, bulk reads, repeated object enumeration, credential failures, and changes to the application's access policy. Prepare a containment path that can revoke the workload credential, block the route, stop the workload, preserve evidence, and identify affected records. ## How does Northflank connect AI-built applications to company systems? If your platform team needs to give AI-built applications controlled access to company systems, Northflank can apply the infrastructure controls around that data path. Your application and data systems still retain record-level authorization. - **Private connectivity:** Keep application, API, and database traffic off the public internet with [private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank#private-networking). - **Runtime secrets:** Keep credentials out of generated code by [injecting secrets](https://northflank.com/docs/v1/application/secure/inject-secrets) only into the workloads that need them. - **Delegated platform access:** Use [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control) and [scoped API roles](https://northflank.com/docs/v1/application/secure/grant-api-access) instead of giving builders broad infrastructure access. - **Environment boundaries:** Separate applications, teams, and environments into [projects](https://northflank.com/features/infrastructure-layer) with namespace-based network and resource boundaries. - **Audit evidence:** Correlate [platform audit logs](https://northflank.com/docs/v1/application/observe/audit-logs), service logs, and metrics with application data-access events. - **Agent-native operations:** Let coding agents deploy and operate workloads through [Northflank Skills](https://github.com/northflank/skills), the [API](https://northflank.com/docs/v1/api/use-the-api), and [CLI](https://northflank.com/docs/v1/api/use-the-cli) within assigned permissions. - **Isolated execution:** Use [Northflank Sandboxes](https://northflank.com/product/sandboxes) when your application needs to execute generated, user-supplied, or otherwise untrusted code. - **Infrastructure placement:** Run APIs, workers, and stateful services on [Northflank Cloud](https://northflank.com/cloud/northflank), or use [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud) when workloads and workload data must remain in your cloud account and VPC. Evaluate control-plane metadata separately. - **Compliance support:** Support security and procurement reviews with a platform that is [SOC 2 Type 2 compliant and HIPAA compliant](https://northflank.com/security), with BAAs available under Enterprise contracts. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to map your identity, data flows, private connectivity, cloud placement, and release requirements. ## Frequently asked questions about connecting vibe-coded apps to company data ### Can a vibe-coded app safely connect directly to a production database? It can for a tightly bounded workload with a restricted backend identity and enforceable database permissions. A purpose-built API is often easier to govern for multiple users or sensitive records. Northflank can [connect database secrets to selected workloads](https://northflank.com/docs/v1/application/databases-and-persistence/connect-database-secrets-to-workloads) without exposing the database publicly. ### Is private networking enough to protect company data? Not on its own. Private networking reduces exposure, while per-request authorization decides which user may access a record. Northflank can provide the private-networking layer; your application and data systems enforce the record-level policy. ### Should a vibe-coded app use production data during development? Not by default. Use separate resources and approved synthetic, masked, or minimized datasets. Northflank [preview blueprints](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) and environment-scoped [secret groups](https://northflank.com/docs/v1/application/secure/manage-secret-groups) can keep preview workloads separate from production credentials and data paths. ## Related articles about secure AI-built application infrastructure - [How to deploy AI-built applications securely in your own cloud](https://northflank.com/blog/securely-deploy-ai-applications-in-your-cloud) - [How to build an enterprise platform for deploying AI-generated applications](https://northflank.com/blog/build-enterprise-ai-application-platform) - [How to deploy an AI agent from sandbox to production](https://northflank.com/blog/how-to-deploy-ai-agent-from-sandbox-to-production)

Best Blacksmith alternatives in 2026

2026-08-14T15:00:00.000Z

## TL;DR: What are the best Blacksmith alternatives in 2026? Blacksmith is a CI platform focused on accelerating GitHub Actions with faster runners and build infrastructure. 1. **Northflank:** Best for teams that need CI/CD alongside application hosting, databases, GPUs, secure sandboxes, preview environments, networking, and BYOC. 2. **GitHub Actions:** Best for teams that want native CI/CD integrated directly into GitHub. 3. **Depot:** Best for teams focused on fast GitHub Actions runners and container build acceleration. 4. **Namespace:** Best for teams looking for faster GitHub Actions infrastructure and developer environments. 5. **Buildkite:** Best for teams that need highly customizable CI infrastructure and control over build agents. 6. **CircleCI:** Best for teams looking for a mature, dedicated CI/CD platform. > **If you need more than faster CI:** [Northflank](https://northflank.com/) combines CI/CD with the infrastructure required to deploy and run applications, including databases, GPUs, secure sandboxes, preview environments, and networking. You can run workloads on Northflank or in your own cloud through BYOC. [Get started with Northflank](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > Blacksmith is a CI/CD platform built around fast, scalable GitHub Actions runners. It gives engineering teams access to more compute, faster build times, and dedicated infrastructure without requiring them to manage their own runner fleet. For teams running large or resource-intensive CI pipelines, it can be a compelling alternative to GitHub-hosted runners. However, Blacksmith is not the right fit for every team. You may want more control over where your CI workloads run, support for other CI/CD workflows, a broader application infrastructure platform, or the ability to run workloads in your own cloud environment. In this guide, we compare six Blacksmith alternatives, their key capabilities, and which teams they are best suited for. ## What to look for in a Blacksmith alternative Before choosing an alternative to Blacksmith, consider what you actually need from your CI infrastructure: - **CI/CD capabilities:** Look for support for automated builds, tests, deployments, and workflow orchestration across your repositories. - **Compute options:** Consider whether you need standard CPU runners, high-performance compute, GPUs, or the ability to choose where your workloads run. - **Build performance:** Faster runners, caching, parallel execution, and efficient resource allocation can significantly reduce CI/CD times. - **Infrastructure flexibility:** Check whether the platform supports managed infrastructure, your own cloud account, or self-hosted environments. - **Container and Kubernetes support:** If your workflows build and deploy containers, look for native support for container registries, Kubernetes, and modern deployment workflows. - **Security:** Evaluate isolation, secrets management, RBAC, SSO, and other controls needed to safely run CI/CD workloads. - **Scalability:** The platform should be able to handle increasing build volumes and concurrent workflows without creating infrastructure bottlenecks. - **Developer experience:** Look for straightforward configuration, Git integration, useful logs, and tooling that makes workflows easy to create and troubleshoot. - **Pricing:** Compare not just the cost per runner or build minute, but also compute, storage, caching, and infrastructure costs as your CI/CD usage grows. ## What are the best Blacksmith alternatives in 2026? The following sections cover each alternative by what it provides, how it differs from Blacksmith, and which teams it suits. ### 1. Northflank [Northflank](https://northflank.com/) is an AI runtime platform that provides [CI/CD](https://northflank.com/docs/v1/application/release/ci-cd-on-northflank), [application hosting](https://northflank.com/product/deployments), [managed databases](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), [GPU workloads](https://northflank.com/product/gpu-paas), [secure sandboxes](https://northflank.com/product/sandboxes), [preview environments](https://northflank.com/product/preview-environments), networking, and infrastructure management from a single platform. Unlike Blacksmith, which focuses primarily on providing high-performance infrastructure for CI workloads, Northflank covers the infrastructure required to build, deploy, and run applications. Northflank supports Git-based CI/CD workflows while also providing the production infrastructure around those workflows. Teams can deploy applications, provision databases, run GPU workloads, create preview environments, and manage infrastructure through the same platform. Northflank also supports [BYOC](https://northflank.com/product/bring-your-own-cloud), allowing teams to run workloads in their own cloud infrastructure. **Key capabilities:** - Built-in CI/CD pipelines triggered from Git commits and pull requests. - Application deployments across Kubernetes and other supported infrastructure. - Preview environments for testing changes in isolated environments. - Managed databases including PostgreSQL, MySQL, MongoDB, and Redis. - GPU workloads for AI inference, training, and batch workloads. - Secure sandboxes for running untrusted or AI-generated code. - BYOC across AWS, GCP, Azure, Oracle, and other supported environments. - Enterprise controls including RBAC, SSO, secrets management, and audit logging. **Best for:** Teams that need CI/CD alongside application hosting, databases, GPUs, secure sandboxes, preview environments, networking, and BYOC. **Considerations:** Northflank provides a broader application and infrastructure platform than Blacksmith, so teams looking only for faster GitHub Actions runners may not need its full range of capabilities. ### 2. GitHub Actions GitHub Actions is GitHub's native CI/CD platform for automating builds, tests, and deployments. Workflows are defined in YAML and triggered by events such as pushes, pull requests, and scheduled runs. Teams can use GitHub-hosted runners or manage their own self-hosted runners. Unlike Blacksmith, which provides optimized infrastructure for running CI workloads, GitHub Actions provides the workflow orchestration layer and the ecosystem around it. Teams can customize workflows with thousands of community and official Actions, connect them to GitHub repositories, and choose between hosted and self-hosted execution environments. **Key capabilities:** - Native integration with GitHub repositories and pull requests. - YAML-based workflow configuration. - GitHub-hosted and self-hosted runners. - Large marketplace of reusable Actions. - Matrix builds and parallel workflow execution. - Secrets, environments, and deployment protection rules. - Integrations with cloud providers, containers, Kubernetes, and other services. **Best for:** Teams that want CI/CD tightly integrated with their GitHub repositories and development workflow. **Considerations:** Teams with high CI volumes may need to evaluate runner costs, concurrency, and performance. GitHub Actions also does not provide integrated application hosting or managed databases. ### 3. Depot Depot provides high-performance CI infrastructure designed to accelerate GitHub Actions workflows and container builds. It combines fast compute with remote build infrastructure and caching to reduce the time spent waiting for CI pipelines and Docker builds to complete. Depot is particularly focused on the performance side of CI. Teams can use Depot as an alternative to standard GitHub-hosted runners when build times, Docker build performance, and caching are major bottlenecks. This makes it a closer alternative to Blacksmith than broader application platforms. **Key capabilities:** - High-performance GitHub Actions runners. - Remote BuildKit for faster container builds. - Persistent and distributed build caching. - Support for x86 and ARM compute. - GPU-enabled CI workloads. - Docker and container build acceleration. - Integration with existing GitHub Actions workflows. **Best for:** Teams focused on faster GitHub Actions runners and container build acceleration. **Considerations:** Depot focuses primarily on CI and build infrastructure. Teams that also need application hosting, databases, preview environments, or production infrastructure will need additional tooling. ### 4. Namespace Namespace provides high-performance infrastructure for CI workloads and development environments. It focuses on giving engineering teams faster compute and flexible environments without requiring them to manage traditional infrastructure themselves. For teams evaluating Blacksmith alternatives, Namespace can be useful when CI performance is only part of the requirement, and developers also need reproducible environments for building and testing software. Its infrastructure can support GitHub Actions workflows while providing environments beyond the individual CI runner. **Key capabilities:** - High-performance GitHub Actions infrastructure. - Ephemeral compute environments. - Developer environments for building and testing applications. - Containerized workloads. - Configurable compute resources. - Infrastructure designed for repeatable development and CI environments. **Best for:** Teams looking for faster GitHub Actions infrastructure alongside flexible developer environments. **Considerations:** Namespace is primarily focused on CI and development infrastructure rather than providing a complete application platform with managed databases and production hosting. ### 5. Buildkite Buildkite provides CI/CD through a hybrid architecture where the control plane manages pipeline orchestration while build agents execute workloads on infrastructure controlled by the customer or through Buildkite-hosted agents. This gives engineering teams significant control over where and how CI jobs run. Buildkite is particularly suited to organizations with complex CI requirements that need customized build environments, large amounts of concurrency, or infrastructure that cannot easily run on standard hosted runners. Its agent-based architecture allows teams to connect CI pipelines to cloud, VM, container, or on-premises infrastructure. **Key capabilities:** - Cloud-managed CI/CD control plane. - Self-hosted and hosted build agents. - Highly customizable build environments. - Dynamic pipeline generation. - Parallel and concurrent builds. - Plugin ecosystem for extending pipelines. - Support for cloud, VM, container, and on-premises infrastructure. **Best for:** Teams that need highly customizable CI infrastructure and control over build agents. **Considerations:** Buildkite provides substantial infrastructure flexibility, but teams using self-hosted agents are responsible for provisioning and managing the underlying infrastructure. ### 6. CircleCI CircleCI is a dedicated CI/CD platform for automating builds, tests, and deployments. It supports cloud-hosted and self-hosted runners and provides configurable execution environments for Docker, Kubernetes, and virtual machines. CircleCI is a mature option for teams that want more control over their CI pipelines without building a CI platform themselves. It provides features for caching, parallel execution, resource configuration, and integrations with common source control and cloud platforms. **Key capabilities:** - YAML-based CI/CD pipeline configuration. - Cloud-hosted and self-hosted runners. - Docker, Kubernetes, and VM execution environments. - Dependency and Docker caching. - Test parallelism and configurable resource classes. - Integrations with GitHub, GitLab, Bitbucket, AWS, GCP, and Azure. - Autoscaling support for self-hosted runner fleets. **Best for:** Teams looking for a mature, dedicated CI/CD platform. **Considerations:** CircleCI focuses on CI/CD rather than application infrastructure. Teams that need integrated application hosting, managed databases, GPUs, or preview environments will need additional tooling. ## How to choose the right Blacksmith alternative The right Blacksmith alternative depends on what your team needs from its CI infrastructure and whether you need more than faster build execution. For teams that need CI/CD combined with application hosting, managed databases, GPUs, secure sandboxes, and preview environments in a single platform, **Northflank** provides these capabilities through one control plane. For teams focused primarily on faster GitHub Actions infrastructure, **Depot** and **Namespace** provide specialized CI infrastructure. For teams that need highly customizable build infrastructure and control over their agents, **Buildkite** is a strong option. **GitHub Actions** is the natural fit for teams that want native GitHub integration, while **CircleCI** is suited to teams looking for a mature, dedicated CI/CD platform. ## FAQs: best Blacksmith alternatives ### What is the best Blacksmith alternative? There is no single best alternative for every team. **Northflank** is a strong choice for teams that need CI/CD plus application infrastructure, while **Depot** and **Namespace** are better suited to teams primarily looking to accelerate GitHub Actions. GitHub Actions itself is the simplest option for teams that want native CI/CD inside GitHub. ### Is Blacksmith better than GitHub Actions? Blacksmith is designed to improve the GitHub Actions experience rather than replace GitHub's workflow syntax. It provides managed runners with faster compute, caching, Docker build acceleration, and CI observability. If your GitHub Actions workflows already perform well, there may be little reason to add another runner provider. If build speed or CI cost is a significant problem, a managed runner platform can be worth considering. ### Is Northflank a Blacksmith replacement? Yes, but it is a broader alternative rather than a like-for-like GitHub Actions runner replacement. Blacksmith focuses on accelerating GitHub Actions. Northflank provides CI/CD alongside the infrastructure required to deploy and operate applications, including services, databases, GPUs, jobs, preview environments, and secure execution environments. ### Can I use GitHub Actions with Northflank? Yes. Northflank supports Git-based workflows and can also be used alongside GitHub Actions. Its platform includes CI/CD and deployment workflows for building and deploying applications. ### Can I run CI infrastructure in my own cloud? Yes. Several platforms support self-hosted or customer-controlled infrastructure. GitHub Actions supports self-hosted runners, while Northflank's BYOC model deploys the platform into your own cloud infrastructure. Depot also offers a managed deployment model where its data plane can run in a customer's AWS account. ### What should I choose if I only need faster GitHub Actions? If you're happy with GitHub Actions and only need faster builds, a specialized runner platform such as Blacksmith, Depot, or Namespace is likely the simplest choice. If you're also looking for application hosting and production infrastructure, a broader platform such as Northflank may be a better long-term fit. ## Conclusion Blacksmith is a strong option for teams that primarily need faster, more powerful CI infrastructure for GitHub Actions. But the right alternative depends on what your team needs beyond CI performance. GitHub Actions works well for teams that want native GitHub integration, while Depot and Namespace focus on faster CI infrastructure. Buildkite provides more control over build agents, and CircleCI offers a mature dedicated CI/CD platform. For teams that need more than CI, Northflank provides a broader platform for the entire application lifecycle. You can build and deploy applications, provision databases, run GPUs, create preview environments, execute untrusted code in secure sandboxes, and manage networking and observability through the same platform. With BYOC, you can also run these workloads in your own cloud environment. [Get started with Northflank](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to see how Northflank can support your CI/CD and application infrastructure. ## Related articles - [Best platforms for hosting AI agents](https://northflank.com/blog/best-platforms-to-host-ai-agents) - [What is BYOC in cloud computing?](https://northflank.com/blog/what-is-byoc-in-cloud-computing) - [How to set up CI/CD for a vibe-coded app](https://northflank.com/blog/how-to-set-up-ci-cd-for-a-vibe-coded-app) - [Top AI tools for CI/CD pipeline automation](https://northflank.com/blog/top-ai-tools-cicd-pipeline-automation)

How to deploy an AI agent from sandbox to production

2026-08-13T16:17:00.000Z

An AI agent uses a model to plan work and call tools with varying autonomy. A successful sandbox run proves it can complete a task, not that your enterprise has a secure, governed production service. Production adds controls for shared ownership: scoped access, isolation, repeatable releases, data boundaries, audit evidence, cost limits, and incident response. This guide explains how to deploy an AI agent from sandbox to production, covering requirements, secure runtime design, testing, release, and operations. It also examines when to build the platform internally and how Northflank runs the agent and supporting stack. ## TL;DR: How to deploy an AI agent from sandbox to production A practical path packages and tests the orchestrator, then promotes it through a controlled release. - Define the agent's inputs, outputs, tools, identity, state, limits, and failure behavior before choosing production infrastructure. - Keep sandbox isolation in the production architecture when the agent executes generated, user-supplied, or otherwise untrusted code. - Version the code, prompts, tool schemas, policy, and model configuration that determine behavior. - Test task quality, permissions, failure handling, security, and load against the full stack, not only the model response. - Release progressively, monitor agent and infrastructure behavior together, and prepare separate recovery for code, data, memory, and external side effects. - Decide whether to build and maintain these controls or adopt a platform that applies them across sandboxes and the production stack. If your organization needs to move agents into production without integrating separate tools for sandboxing, Kubernetes, CI/CD, databases, secrets, and observability, [Northflank](https://northflank.com/) provides one deployment and governance model for agent sandboxes and the surrounding application stack. Platform teams can give developers a self-service path while retaining control over infrastructure placement, access, releases, and audit evidence. Run on [Northflank Cloud](https://northflank.com/cloud/northflank) or use self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud) when private networking, regional placement, existing cloud commitments, or workload data boundaries make customer-controlled infrastructure important. [Northflank Skills](https://github.com/northflank/skills) lets supported coding agents operate the stack through the API and CLI within assigned permissions. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book an architecture review](https://cal.com/team/northflank/northflank-demo?duration=30) to map your agent runtime, security boundary, data flows, cloud placement, and production release requirements. ## What changes when an AI agent moves from sandbox to production? Moving an AI agent to production adds a controlled service boundary around variable outputs and execution paths. It does not mean removing the sandbox, an isolated environment for code and commands. During development, one sandbox may contain the agent, tools, code, temporary files, and developer credentials. The agent orchestrator authenticates callers, applies policy, invokes the model, and coordinates tools. When required by the threat model, it isolates generated code, shell commands, unfamiliar dependencies, or unsafe file-processing tools. Durable records should typically live elsewhere. This gives platform and security teams control over scaling, quotas, network policy, credentials, and termination. ## What should you define before deploying an AI agent? An agent production contract defines the interface, authority, resources, and failure behavior the deployed system must enforce. Define it before packaging so each requirement is testable. | Decision | Define | Why it affects production | | --- | --- | --- | | Interface | Request, event, and response schemas | Enables validation, versioning, and retries | | Identity | Who invokes the agent and which identity it uses | Determines authorization and attribution | | Tools | Allowed operations, targets, and parameter rules | Sets the agent's maximum authority | | State | Durable records, memory, workspace, and retention | Reduces the risk of temporary state becoming a system of record | | Limits | Time, steps, tokens, cost, concurrency, and resources | Bounds runaway tasks and capacity demand | | Failure behavior | Retry, compensate, escalate, or stop | Reduces duplicate or partially completed actions | | Service objectives | Quality, latency, availability, and cost targets | Creates a production-readiness gate | Keep tool authorization outside model discretion. The model can propose an action, but deterministic controls in the application, policy engine, IAM layer, gateway, or tool server should validate the caller, operation, target, parameters, environment, and approval. Use task-specific credentials. Set thresholds. ## How do you package an AI agent for production? Package the agent as a reproducible, immutable deployment artifact: typically a container image that is not changed after testing. Keep environment-specific configuration and secrets outside it. Version behavior-changing components, including prompts, policy, tool schemas, model and retrieval configuration, and migrations. Record relevant versions with each run. Promote the same artifact across staging and production where practical. Separate components that scale or release independently. If your team wants a direct path from Git to a running agent, a Northflank [combined service](https://northflank.com/docs/v1/application/getting-started/build-and-deploy-your-code) builds and deploys from a linked branch. When the same tested artifact must move through staging and production, separate the build from deployment so each environment references the exact image that passed evaluation. ## How do you test an AI agent before production? Test the agent system because a good response does not prove identity, tools, state, and failure handling work safely. - **Deterministic tests:** Validate schemas, policy, tools, retries, idempotency, and state transitions. - **Task evaluations:** Run representative and edge-case tasks against a versioned dataset. Score completion, correctness, groundedness, and escalation where applicable. - **Security tests:** Exercise prompt injection, malicious tools, permission escalation, approval bypass, memory poisoning, exfiltration, and sandbox escape attempts. - **Resilience tests:** Inject model timeouts, tool failures, partial writes, queue redelivery, and outages. Check retries for duplicate actions. - **Load tests:** Measure latency, errors, queue depth, sandbox starts, model quotas, token use, and cost under expected demand. Where practical, test with representative networks, secret scopes, queues, data, and isolation. A preview tests a change temporarily; staging is a persistent pre-production stage. If reviewers need to evaluate more than the agent API, [Northflank preview blueprints](https://northflank.com/docs/v1/application/release/set-up-preview-blueprints) create an isolated copy of the supporting stack from Git, a webhook, or an API call. The preview can include services, workers, jobs, databases, and test URLs, giving each change a production-like environment without making it permanent. ## What production architecture should an AI agent use? A production AI agent architecture typically separates request handling, orchestration, risky execution, durable state, and operational control. This request path is a practical reference, not a universal standard. ### 1. API or event entry point Here, the entry point authenticates the caller, validates the request, applies limits, and assigns a correlation ID linking events from one run. Asynchronous work can return a durable run ID and enter a queue. Use durable idempotency or deduplication for retried operations. Consequential side effects may also require conditional writes, transactions, an outbox, downstream idempotency, or reconciliation. If the entry point needs to run continuously or scale with request volume, Northflank [deployment services](https://northflank.com/docs/v1/application/run/run-an-image-continuously) can run the API or worker with configurable ports, health checks, and horizontal autoscaling. ### 2. Agent orchestrator and policy layer The orchestrator manages model calls, context, limits, and tool selection. A separate policy layer checks each action against the caller, agent version, resource, and environment. Set budgets for time, steps, tokens, tool calls, and cost. Independently authorize high-impact actions. For the infrastructure side of this boundary, Northflank can [inject secrets](https://northflank.com/docs/v1/application/secure/inject-secrets) into selected workloads, connect the orchestrator to tools over [private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank#private-networking), and scope [platform API access](https://northflank.com/docs/v1/application/secure/grant-api-access) through assigned roles. Your application still decides which agent action is permitted. ### 3. Isolated execution environment Run generated code, shell commands, untrusted repositories, and unsafe file-processing tools outside the orchestrator. Give the environment only the resources, credentials, and network access required. If the production agent must run code it did not author or trust, [Northflank Sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) give the orchestrator an SDK-controlled execution boundary. The service can create a sandbox, execute commands, attach storage when state is required, then pause or destroy the environment at the end of the task. ### 4. State and data services Business records commonly belong in databases, artifacts in object storage, and pending work in queues. Agent memory retained across steps or sessions should have an owner, retention period, access policy, and deletion path. Export required artifacts or attach narrowly scoped storage instead of persisting an entire sandbox. This makes cleanup predictable. When the agent needs durable state, Northflank supports [stateful workloads](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank) alongside the service, including PostgreSQL, MySQL, MongoDB, Redis, RabbitMQ, MinIO object storage, and persistent volumes. This keeps databases, queues, and artifacts separate from disposable execution sessions. ### 5. Observability and incident controls Connect agent traces to infrastructure events with the run ID. Depending on impact, record identity, versions, policy decisions, tools, approvals, resources, state changes, latency, token use, and cost. Capture content only where policy permits. For agents capable of consequential actions, operators need independent controls to terminate runs, revoke credentials, disable tools, block requests, restrict egress (outbound network traffic), and quarantine state. Northflank supplies [service logs and metrics](https://northflank.com/docs/v1/application/production-workloads/production-operations), health checks, alerts, and [platform audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) for the infrastructure layer. Correlate these signals with application-level agent and tool traces using the same run identifier. ## How do you release an AI agent safely? A common release strategy promotes a tested agent version through progressively more realistic and consequential environments. Adapt this path to the workload: 1. Build one versioned artifact from a reviewed commit. 2. Evaluate it in a full-stack preview, then deploy the same artifact to staging. 3. Compare it with the current version, then promote through a bounded rollout. 4. Expand while acceptance criteria hold; stop or restore the previous artifact when they fail. If your team needs a repeatable route between stages, [Northflank Environments](https://northflank.com/docs/v1/application/getting-started/set-up-environments) can model development, staging, and production while workflows automate builds, deployments, backups, migrations, and artifact promotion. Readiness checks keep traffic away from a new service until it can accept work. When a release fails, [Northflank workflows](https://northflank.com/docs/v1/application/release/run-and-manage-workflows) can roll back to previous deployments. Teams can inspect current and previous workflow runs, review the status of individual nodes, and rerun a previous workflow with the same structure and arguments. ## How do you operate and improve the agent in production? Operate the agent as both an AI system and a software service. Uptime can remain healthy while task quality falls. Track task success, policy denials, errors, latency, queues, sandbox startup, token use, cost, and user impact. Segment by agent version, model, tool, task, and environment. Add failures to evaluations; check fixes against other tasks. When the agent is live, Northflank [production operations](https://northflank.com/docs/v1/application/production-workloads/production-operations) expose logs, metrics, notifications, health checks, and horizontal autoscaling for its services. These infrastructure signals help operators diagnose availability and capacity while application evaluations measure whether the agent still performs its task correctly. ## How does Northflank take an AI agent from sandbox to production? Building a production agent platform internally means owning the infrastructure that takes agents from isolated development into governed production: sandbox runtimes, Kubernetes, identity integrations, release automation, databases, observability, upgrades, and incident response. Northflank gives platform teams one control plane for these layers while preserving cloud and architecture choices. See how Northflank capabilities map to the requirements in this deployment path: - **An approved route to production:** [Git-based builds](https://northflank.com/docs/v1/application/build/build-code-from-a-git-repository), [deployment services](https://northflank.com/docs/v1/application/run/run-an-image-continuously), [jobs](https://northflank.com/docs/v1/application/run/run-an-image-once-or-on-a-schedule), and [Northflank Sandboxes](https://northflank.com/product/sandboxes) give developers one delivery path for the agent service, workers, and untrusted execution. [Environments](https://northflank.com/docs/v1/application/release/set-up-environments) and [workflows](https://northflank.com/docs/v1/application/release/configure-workflows) promote tested artifacts through development, staging, and production with [health checks](https://northflank.com/docs/v1/application/observe/configure-health-checks), [migrations](https://northflank.com/docs/v1/application/release/run-migrations), and [rollback](https://northflank.com/docs/v1/application/release/run-and-manage-workflows). - **Production-like evidence before merge:** [Preview environments](https://northflank.com/product/preview-environments) reproduce the agent and supporting stack so reviewers can evaluate the complete change. - **One operating model with infrastructure choice:** [Stateful workloads](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), [private services](https://northflank.com/docs/v1/application/network/networking-on-northflank#private-networking), workers, and [GPU workloads](https://northflank.com/docs/v1/application/gpu-workloads/gpus-on-northflank) can run alongside the agent. [Northflank Cloud](https://northflank.com/cloud/northflank) provides managed infrastructure, while [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud) supports customer-controlled cloud resources, networking, regional placement, and workload data paths. [Northflank Enterprise](https://northflank.com/enterprise) also supports forward-deployed control-plane options. - **Enterprise access and governance:** [Secret injection](https://northflank.com/docs/v1/application/secure/inject-secrets), [private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank#private-networking), [SAML or OIDC SSO](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation#configure-single-sign-on-sso), [MFA enforcement](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation#manage-organisation-security), [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [scoped API roles](https://northflank.com/docs/v1/application/secure/grant-api-access), and [platform audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) provide infrastructure controls and evidence that complement application-level agent traces. - **Compliance support:** Northflank is [SOC 2 Type 2 compliant and HIPAA compliant](https://northflank.com/security), with Business Associate Agreements supported under Enterprise contracts. - **Agent-native operations under assigned access:** [Northflank Skills](https://github.com/northflank/skills) gives supported coding agents guidance for operating services, jobs, databases, previews, sandboxes, GPUs, and releases through the API and CLI. Assigned credentials and permissions remain the access boundary. > [Versaia runs its agent orchestration platform on Northflank](https://northflank.com/blog/versaia-runs-agent-orchestration-platform-on-northflank) for enterprise, healthcare, and public-sector customers. After migrating in under two weeks, Versaia increased voice-agent throughput from 4–5 to 15 concurrent calls per node and cut compute costs by about 60%. > [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book an architecture review](https://cal.com/team/northflank/northflank-demo?duration=30) to map your sandbox boundary, identity, data flows, cloud placement, and releases. ## Frequently asked questions about deploying an AI agent to production These answers distinguish sandboxes and production services. ### Can you deploy a sandbox directly to production? Not usually as-is. Promote the tested artifact with production configuration, identity, data services, health checks, scaling, and observability. Northflank can run the production service and the ephemeral sandboxes it creates under the same deployment model. ### What should you monitor for a production AI agent? Monitor task quality and policy behavior alongside availability, latency, errors, capacity, and cost. Northflank provides infrastructure logs, metrics, health checks, and alerts that you can correlate with application-level agent and tool traces. ### How do you roll back an AI agent? Restore the previous artifact, prompts, policy, tool schemas, and model configuration. Northflank workflows can restore an earlier deployment, while database changes, memory, and external agent actions still require separate recovery. ## Related articles about production AI agent infrastructure - [How to deploy agents securely in enterprises in 2026](https://northflank.com/blog/how-to-deploy-agents-securely-in-enterprises) - [How to use agentic AI in your SDLC](https://northflank.com/blog/how-to-use-agentic-ai-in-your-sdlc) - [Agent-native software development: deploying what coding agents build](https://northflank.com/blog/agent-native-software-development) - [How to sandbox AI agents](https://northflank.com/blog/how-to-sandbox-ai-agents) - [What is the best deployment stack for AI apps in 2026?](https://northflank.com/blog/best-deployment-stack-for-ai-apps)

Persistent vs ephemeral AI sandboxes: Which should you use?

2026-08-13T16:16:00.000Z

Choosing one sandbox lifecycle for every task creates problems. Make every environment ephemeral and agents may repeatedly rebuild useful workspace state; make every environment persistent without effective lifecycle controls and stale files, dependencies, and storage can accumulate after the work ends. The choice between persistent and ephemeral AI sandboxes depends on what must survive, for how long, and behind which security boundary. This guide compares their state, performance, cost, security, and operations, including when to use or combine them in production. ## TL;DR: Persistent vs ephemeral AI sandboxes Use ephemeral AI sandboxes by default for independent, reproducible tasks. Use persistent sandboxes when filesystem continuity is part of the workflow, and combine both when an agent needs a durable workspace plus disposable execution. - Choose ephemeral sandboxes for one-shot code execution, CI and evaluation runs, independent RL rollouts, and parallel work that should start clean. - Choose persistent sandboxes for coding agents, interactive workspaces, and tasks where repositories, packages, and generated files must survive. - Define persistence precisely. Filesystem, process, memory, network identity, and external application records are different state layers. - Compare workload cost, including repeated ephemeral setup and persistent storage and cleanup. - Treat lifecycle and isolation separately. Destroying an environment after use does not replace microVM or user-space-kernel isolation, network controls, scoped credentials, and reliable teardown. If your AI system needs clean per-task execution and resumable workspaces, [Northflank Sandboxes](https://northflank.com/product/sandboxes) support ephemeral and volume-backed persistent sandboxes on one platform. Persistent environments can scale to zero to stop compute billing while retaining their configuration and volume, then resume later. Run both sandbox types on [Northflank Cloud](https://northflank.com/cloud/northflank) or use self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud) to deploy them in your cloud account. APIs, workers, databases, jobs, object storage, and GPU workloads can run alongside the sandboxes, keeping the agent stack on one platform. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or sandbox lifecycle requirements. ## What is the difference between persistent and ephemeral AI sandboxes? An ephemeral AI sandbox has its writable execution state discarded or reset after its task, while a persistent AI sandbox retains selected state for a later session. Both remain sandboxes, so both need an enforced boundary between executed code, the host, other tenants, and connected systems. | Decision | Ephemeral AI sandbox | Persistent AI sandbox | | --- | --- | --- | | State after task | Discarded or reset | Selected state retained | | Starting point | Clean image or template | Existing workspace or retained volume | | Best for | Independent, reproducible tasks | Multi-step, stateful workflows | | Repeated setup | Repeated unless prebuilt or cached | Amortised across sessions | | Retained storage | Typically minimal; external state may persist | Needs quotas, retention, and deletion | | Main operational pressure | Creation and teardown | Resumption, patching, and stale state | The important word is “selected.” A persistent filesystem can retain repositories, packages, caches, and generated files. Preserving memory, running processes, open connections, or network identity requires a continuously running environment or explicit runtime checkpoint-and-restore. Durable application state is another layer. User identity, task status, audit events, and agent memory usually belong in a database or object store rather than one sandbox. ## When should you use ephemeral AI sandboxes? Use ephemeral sandboxes when a task can run from controlled inputs and nothing in its workspace needs to survive. Each task starts from a known image or template, performs its work, returns the result, and has its writable environment reset or destroyed. Common uses include: - one-shot execution of model-generated or user-submitted code - CI, test, and evaluation jobs - independent reinforcement-learning rollouts - per-request file or data transformations - parallel candidate implementations and test branches A clean start can improve reproducibility and reduce cross-run contamination. When writable state is fully reset, a package installed by one task cannot quietly change the next. For more on lifecycle and isolation choices, see [ephemeral sandbox environments](https://northflank.com/blog/ephemeral-sandbox-environments). With Northflank, you can [start an ephemeral sandbox](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#starting-an-ephemeral-sandbox) from a public or private container image using the JavaScript SDK. If the sandbox does not need to retain workspace data across restarts or scale-to-zero, configure ephemeral storage without attaching a persistent volume. Using ephemeral storage without an attached persistent volume keeps each sandbox disposable, but setup not captured in the image or an external cache must be repeated. If every run checks out the same repository, downloads dependencies, and prepares the same dataset, setup becomes part of the critical path. An agent that returns to one workspace over many calls may need persistence rather than another cold-start optimisation. Running ephemeral sandboxes at scale requires scheduling, credential issuance, teardown, and orphan detection. If deletion fails, abandoned environments can continue consuming compute or storage and retain credentials, network access, or temporary data longer than intended. ## When should you use persistent AI sandboxes? Use persistent sandboxes when retained workspace state is necessary to continue the task or user experience. A coding agent can clone a repository, install dependencies, edit, test, disconnect, and return to the same files later. Persistence also fits agent-backed development workspaces, research workflows that revise local artefacts over time, and data tasks that build an intermediate working set. A long-running service with local durable state may need persistent storage too, but retained files alone do not keep a process alive. Treat runtime continuity and filesystem continuity as separate requirements. Persistent sandboxes reduce setup because agents can reuse files, dependencies, and build artefacts. The trade-off is dependency drift, accumulated temporary files, compromised state surviving reconnection, and abandoned volumes consuming storage. Persistent environments need maximum-age and idle policies, storage quotas, reset and deletion controls, and retained-state inspection or quarantine. [Northflank persistent volumes for sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#create-sandbox-with-volume-for-persistence) preserve data written to their mount paths across restarts and pauses, so agents can return to the same files, installed dependencies, and working directory in later sessions. You can scale the sandbox to zero to stop compute billing while retaining its service configuration and volume, then scale it back up when the agent returns. This preserves stored files, not in-memory process state. When you no longer need the sandbox and its persisted data, you can [delete the sandbox service and its volume separately](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#pause-or-destroy-the-sandbox). ## How do persistent and ephemeral sandboxes compare on cost and performance? Neither lifecycle is always cheaper or faster. Cost and performance depend on setup, compute time, and retained state. Ephemeral sandbox costs include execution, setup, data transfer, and lifecycle overhead. A short evaluator receiving all inputs per request may gain little from workspace retention when setup is inexpensive. Persistent sandbox costs include execution, storage, optional backups, and stale environments. A coding agent using one repository across sessions may save time and compute by retaining dependencies and build artefacts. Scale-to-zero can provide a middle ground between paying for continuously running compute and rebuilding a workspace from scratch. On Northflank, [pausing a sandbox](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#pause-or-destroy-the-sandbox) stops compute billing while keeping the volume and service configuration intact, so only retained volume storage is billed while paused. Separating compute from persistent storage can suit workloads with long idle periods when retaining the files costs less than rebuilding the workspace. To compare cost and performance, measure the workload rather than startup alone. Track time to interactive, task completion, creation success, resume latency, storage, cleanup lag, and environments left after failed deletion. ## Are ephemeral AI sandboxes more secure than persistent ones? Not inherently. Ephemeral sandboxes shorten the lifetime of retained state, while persistent sandboxes require more controls around accumulated state. Both still need isolation appropriate to the code being executed. An ephemeral container with a weak tenant boundary can still be compromised during its short life. A persistent microVM may provide a stronger runtime boundary while creating more retained-state risk. Lifecycle and isolation answer different questions. For untrusted or model-generated code, evaluate runtime isolation, network access, credentials, resource limits, and incident controls together. Hardware-virtualised microVMs give workloads a separate kernel boundary. gVisor uses a user-space kernel; it is not a microVM. Credentials should be scoped and short-lived, while network access should expose only required destinations. Northflank supports [microVM-based and user-space-kernel isolation](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank), depending on the workload and infrastructure. If your enterprise also needs control over infrastructure placement, [Northflank BYOC sandbox clusters](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-in-your-cloud) run sandbox workloads on microVM-enabled node pools in your cloud account. Runtime availability varies by cloud provider and region. Isolation controls how sandbox code runs; lifecycle controls govern what follows. Persistent sandboxes need expiry, workspace reset, credential revocation, quarantine, and volume-deletion controls. Ephemeral sandboxes need teardown retries and deletion checks. ## When should you combine persistent and ephemeral sandboxes? Combine both models when the parent task needs continuity but individual actions should remain isolated or disposable. A persistent parent workspace with ephemeral child sandboxes works well for long-horizon agents. ### 1. Keep the long-horizon workspace persistent Retain the repository, installed dependencies, and named artefacts for the user or task. In most production systems, keep durable identity, task records, audit events, and agent memory in an external database rather than making the sandbox filesystem your only system of record. ### 2. Launch ephemeral children for risky or parallel work Use disposable sandboxes for tests, untrusted tools, candidate branches, and evaluations. Return only the required result or reviewed artefact, then destroy the child. ### 3. Apply lifecycle policy to both In production, persistent parent sandboxes typically need retention, quotas, reset, and deletion controls. Ephemeral child sandboxes need teardown and orphan detection, with duration limits where appropriate. At scale, lifecycle volume can rival environment count; [running concurrent AI sandboxes at scale](https://northflank.com/blog/how-to-run-millions-concurrent-ai-sandboxes) requires capacity and cleanup to be designed together. ## How can you run both persistent and ephemeral AI sandboxes on Northflank? Northflank supports ephemeral and persistent AI sandboxes through one platform and SDK. Unlike a sandbox-only runtime, Northflank runs workloads surrounding agent execution. > Northflank is a strong fit when you need persistent and ephemeral sandboxes as part of a production AI stack, rather than as a standalone code-execution API. > - **Ephemeral and persistent execution:** Northflank provides [ephemeral sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#starting-an-ephemeral-sandbox) with disposable storage and [persistent volumes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#create-sandbox-with-volume-for-persistence) that retain files across restarts and pauses. Both models can run public or private container images. - **Isolation and infrastructure placement:** Northflank applies hardware-virtualised microVM [isolation](https://northflank.com/product/sandboxes) with Kata Containers or Firecracker, or gVisor user-space-kernel isolation, to [sandbox workloads](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank), depending on the workload and infrastructure. Sandboxes can run on [Northflank Cloud](https://northflank.com/cloud/northflank) or through [self-serve BYOC](https://northflank.com/features/bring-your-own-cloud) on microVM-enabled node pools, subject to provider and region availability. - **Lifecycle and cost control:** [Persistent sandboxes can scale to zero](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#create-sandbox-with-volume-for-persistence) while retaining volume data and service configuration, then resume when needed. - **Production AI stack:** Northflank runs [APIs and workers](https://northflank.com/docs/v1/application/run/run-an-image-continuously), [jobs](https://northflank.com/docs/v1/application/run/run-an-image-once-or-on-a-schedule), [databases](https://northflank.com/docs/v1/application/databases-and-persistence/deploy-a-database), [object storage](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), and [GPU sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#create-a-gpu-sandbox) alongside sandbox execution. - **Enterprise governance:** Northflank supports identity and access with [SAML or OIDC SSO](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation), [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), and [scoped API access](https://northflank.com/docs/v1/application/secure/grant-api-access). [Network policies](https://northflank.com/docs/v1/application/network/configure-network-policies) control traffic, [secret injection](https://northflank.com/docs/v1/application/secure/inject-secrets) supplies configured credentials, and [platform audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) record platform events. Your application remains responsible for tenant authorization and agent traces. - **Compliance:** Northflank is [SOC 2 Type 2 compliant and HIPAA compliant](https://northflank.com/security), with BAAs supported under Enterprise contracts. - **Agent-native operations:** [Northflank Skills](https://github.com/northflank/skills) helps supported coding agents deploy, operate, and automate sandboxes and surrounding workloads through the API and CLI, within assigned credentials and permissions. - **Operational interfaces:** The stack is available through Northflank's [API](https://northflank.com/docs/v1/api/use-the-api), [JavaScript SDK](https://northflank.com/docs/v1/api/use-the-javascript-client), [CLI](https://northflank.com/docs/v1/api/use-the-cli), [UI](https://northflank.com/docs/v1/application/getting-started/introduction-to-northflank), and [GitOps](https://northflank.com/docs/v1/application/infrastructure-as-code/gitops-on-northflank). [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or sandbox lifecycle requirements. ## Frequently asked questions about persistent vs ephemeral AI sandboxes ### Do AI agents always need persistent sandboxes? No. AI agents doing independent tasks can use ephemeral sandboxes. Agents returning to one working directory across sessions can benefit from persistence because files and dependencies remain available. ### Does a persistent sandbox keep running processes alive? It depends on the mechanism. A retained volume preserves files, while runtime checkpoint-and-restore or a continuously running environment preserves process state. Northflank's scale-to-zero workflow retains service configuration and volume data, not in-memory processes. ### Can an ephemeral sandbox use persistent storage? Yes. Compute can be short-lived while selected data lives in a volume, object store, or database. On Northflank, you can use ephemeral storage for disposable files and [attach a persistent volume](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#create-sandbox-with-volume-for-persistence) to paths that must survive restarts or pauses. ### Should each user get one persistent sandbox? It depends on your tenancy model. A user-level workspace can fit interactive development, while task-level persistence reduces state sharing and allows more precise expiry. ### How long should a persistent AI sandbox live? Tie retention to the task and data policy. Combine idle pause with a maximum age, storage quota, and deletion rule. On Northflank, persistent sandboxes can [scale to zero](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#pause-or-destroy-the-sandbox) while retaining volume data and service configuration. ## Related articles to AI sandbox lifecycle and infrastructure - [What are persistent sandboxes?](https://northflank.com/blog/persistent-sandboxes) - [Ephemeral sandbox environments](https://northflank.com/blog/ephemeral-sandbox-environments) - [What is sandbox infrastructure?](https://northflank.com/blog/what-is-sandbox-infrastructure) - [How to run millions of concurrent AI sandboxes](https://northflank.com/blog/how-to-run-millions-concurrent-ai-sandboxes) - [Running reinforcement-learning agents in secure sandboxes](https://northflank.com/blog/reinforcement-learning-agents-in-secure-sandboxes)

How to self-host Kimi K3 on AWS

2026-08-13T14:00:00.000Z

Kimi K3 is a large open-weight model designed for reasoning, coding, long-context tasks, and AI agents. For teams that want to run Kimi K3 themselves, AWS provides the infrastructure needed to keep the model and its supporting services inside an environment they control. Self-hosting a model at this scale is different from deploying a typical application. You need substantial GPU capacity, distributed inference, networking, storage, and a platform for managing the workloads around the model. For enterprises, this means either building and operating that infrastructure themselves or using a platform that can provide the management layer within their own cloud environment. >This is a high-level guide to self-hosting Kimi K3 on AWS, with links to detailed documentation and hands-on guides for the implementation. ## TL;DR: how to self-host Kimi K3 on AWS Self-hosting Kimi K3 gives enterprises more control over where their model runs, how it connects to internal systems, and where inference data is processed. With [Northflank](https://northflank.com/), you can: - Run Kimi K3 inside your own AWS account and VPC - Use your existing AWS infrastructure and cloud commitments - Manage Kimi K3 deployments through Northflank - Keep model workloads and data within your AWS environment - Apply enterprise controls such as RBAC, SSO, secrets management, and audit logging - Run Kimi K3 alongside the applications, databases, and services it depends on > [Get started with Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your Kimi K3 deployment. > ## Why self-host Kimi K3? Using the Kimi API is the simplest way to access Kimi K3, but some enterprises need more control over where their AI workloads run. Running Kimi K3 inside your own AWS environment means the model can operate alongside your existing applications, databases, and private services instead of sending inference workloads to an external hosted environment. Self-hosting can also make sense when you have existing AWS infrastructure or committed cloud spend, need to meet internal data and security requirements, or want greater control over the model serving environment. The tradeoff is that you take on the infrastructure required to run a model of Kimi K3's scale. Kimi K3 is open-weight, but enterprises should review its license and commercial-use conditions before deploying it in production to ensure their intended use complies with the applicable terms. ## What does Kimi K3 need to run? Kimi K3 is a 2.8-trillion-parameter sparse Mixture-of-Experts model with a 1-million-token context window. Its model weights are around 1.56 TB in the current repository, making it a substantial distributed GPU workload rather than a typical single-GPU deployment. That means a production deployment needs more than GPU capacity. You also need high-performance networking between accelerators, persistent storage for model weights, an inference engine such as vLLM, and the infrastructure to deploy, monitor, secure, and operate the resulting service. ## What is Northflank? [Northflank](https://northflank.com/) is a runtime platform for AI-native companies deploying and managing applications, infrastructure, and AI workloads. It can run on [Northflank's managed cloud](https://northflank.com/features/managed-cloud), inside your own cloud environment through [Bring Your Own Cloud (BYOC)](https://northflank.com/product/bring-your-own-cloud), or as a [forward-deployed control plane](https://northflank.com/enterprise). With BYOC, Northflank deploys and manages your workloads **within your AWS account and VPC** while you retain control of the underlying infrastructure. This means you can use your own AWS compute, networking, storage, and GPU capacity while managing your workloads through the Northflank platform. Northflank provides the infrastructure and developer tooling needed to run AI workloads and the applications around them, including [GPU compute](https://northflank.com/product/gpu-paas), [secure sandboxes](https://northflank.com/product/sandboxes), [managed databases](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), persistent storage, [preview environments](https://northflank.com/product/preview-environments), CI/CD, networking, observability, and [enterprise security controls](https://northflank.com/enterprise). For Kimi K3, this gives enterprises a way to combine the control of self-hosting with a managed platform experience. Instead of building and operating the entire application platform around a distributed GPU workload yourself, Northflank provides the tooling for deploying, securing, and managing Kimi K3 alongside the rest of your application infrastructure. ## Why use Northflank to self-host Kimi K3? Running Kimi K3 directly on AWS gives you control over the underlying infrastructure, but it also means managing the platform around the model. Northflank provides that platform layer while allowing the Kimi K3 workload to remain inside your AWS environment. ### 1. Run Kimi K3 in your own AWS environment With BYOC, Kimi K3 runs inside your AWS account and VPC. You retain control over the AWS region, networking, compute, and data, while Northflank provides the platform for deploying and managing the workload. You can also use your existing AWS infrastructure and committed cloud spend rather than creating a separate infrastructure relationship. Northflank does not add a markup to the underlying AWS compute costs. ### 2. Manage GPU infrastructure without building the platform yourself Kimi K3 requires substantial GPU capacity and distributed infrastructure. Operating that directly means dealing with Kubernetes, GPU configuration, networking, deployments, scaling, and monitoring in addition to running the model itself. Northflank provides a consistent platform for managing these workloads in your AWS environment. Your team can provision infrastructure, deploy services, manage workloads, and monitor deployments without having to build and maintain a separate internal platform around Kimi K3. ### 3. Run the rest of your AI application alongside Kimi K3 Kimi K3 is unlikely to be the only component of a production AI application. You may also need APIs, databases, background workers, queues, object storage, scheduled jobs, and other AI services. Northflank lets these workloads run through the same platform as Kimi K3. This gives your team one place to deploy and operate the model and the application infrastructure it depends on, rather than managing each component through separate infrastructure tooling. ### 4. Apply enterprise security and governance Self-hosting gives you control over the underlying AWS environment, but you still need controls around the applications and workloads running inside it. Northflank provides enterprise capabilities including **RBAC, SSO, secrets management, audit logging, and network controls**. Combined with BYOC, this allows enterprises to keep Kimi K3 within their own cloud environment while applying consistent security and governance controls around the model and the applications that interact with it. This is particularly important when Kimi K3 is used by AI agents that access internal data, call private services, or take actions using enterprise credentials. ## How secure is self-hosting Kimi K3 with Northflank? Security starts with where the workload runs. With BYOC, the runtime environment and data remain within your own cloud boundary, giving your organization control over the AWS account, region, networking, and underlying infrastructure. Northflank adds security controls at the platform layer. These include **RBAC** for controlling who can access and manage workloads, **SSO** for integrating with enterprise identity providers, **secrets management** for protecting credentials, and **audit logs** for tracking platform activity. Network configuration can also be managed within your cloud environment. For AI workloads, this separation is useful because the model may interact with sensitive applications, databases, credentials, and internal APIs. Instead of treating Kimi K3 as an isolated model endpoint, you can apply the same security and infrastructure controls around it as you do around the rest of your production environment. ## How to get started You do not need to build an AI infrastructure platform from scratch to self-host Kimi K3 on AWS. The high-level deployment process is: 1. [**Create a Northflank account**](https://app.northflank.com/signup) 2. [**Connect your AWS account to Northflank**](https://northflank.com/docs/v1/application/bring-your-own-cloud/aws-on-northflank). 3. [**Create a BYOC cluster**](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud) in the AWS region where you want to run Kimi K3. 4. [**Provision the required GPU infrastructure**](https://northflank.com/docs/v1/application/gpu-workloads/configure-and-optimise-workloads-for-gpus) for your Kimi K3 deployment. 5. [**Deploy the Kimi K3 inference workload**](https://northflank.com/guides/self-host-vllm-in-your-own-cloud-account-with-northflank-byoc) using a supported inference engine such as vLLM. 6. **Connect your applications and AI agents** to the Kimi K3 inference endpoint. 7. **Manage the workload through Northflank** alongside your other services and infrastructure. For the detailed implementation, see the [GPUs on Northflank documentation](https://northflank.com/docs/v1/application/gpu-workloads/gpus-on-northflank) and [Self-host vLLM in your own cloud account with Northflank](https://northflank.com/guides/self-host-vllm-in-your-own-cloud-account-with-northflank-byoc). You can also [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your Kimi K3 deployment. ## FAQ: self-hosting Kimi K3 on AWS ### Can I run Kimi K3 inside my own AWS VPC? Yes. Northflank BYOC provisions and manages the Kubernetes cluster inside your AWS account, allowing your Kimi K3 workloads and supporting infrastructure to run within your own cloud environment. ### Does Northflank access my Kimi K3 data? With BYOC, the Kimi K3 workload runs within your AWS environment. Northflank provides the platform layer for managing the workload, while your AWS account remains responsible for the underlying infrastructure and data. ### Do I need to manage Kubernetes myself? Northflank BYOC provisions and manages the Kubernetes cluster in your cloud account, reducing the amount of cluster management your team needs to handle directly. You still control the underlying AWS environment and its configuration. ### Can I use my existing AWS GPU infrastructure? Yes, depending on your setup. Northflank supports BYOC for AWS and can also manage existing Kubernetes clusters through BYOK, allowing organizations to bring existing infrastructure into the platform. ### Can I run other applications alongside Kimi K3? Yes. Northflank is designed to run application services, databases, jobs, GPUs, and other workloads through the same platform, so Kimi K3 can be part of a broader AI application architecture rather than operating as an isolated model server. ## Conclusion Self-hosting Kimi K3 on AWS gives enterprises control over where the model runs, how it connects to internal infrastructure, and where inference data is processed. But the scale of Kimi K3 also makes the underlying infrastructure more complex than a typical AI application, particularly when you need distributed GPUs and production-grade networking and operations. Northflank BYOC provides a middle ground between a fully managed AI service and building the entire platform yourself. Kimi K3 runs inside your AWS environment while Northflank provides the platform layer for deploying, securing, and managing the workload and the applications around it. [Get started with Northflank](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to explore self-hosting Kimi K3 in your AWS environment. ## Related articles - [Kimi K3: benchmarks, pricing, hardware requirements, and self-hosting](https://northflank.com/blog/what-is-kimi-k3-self-hosting) - [Self-host vLLM in your own cloud account with Northflank BYOC](https://northflank.com/guides/self-host-vllm-in-your-own-cloud-account-with-northflank-byoc) - [What is BYOC in cloud computing?](https://northflank.com/blog/what-is-byoc-in-cloud-computing) - [Bring your own cloud app hosting: how BYOC works and when to use it](https://northflank.com/blog/bring-your-own-cloud-app-hosting)

Where should enterprises host their AI agents?

2026-08-13T14:00:00.000Z

## TL;DR: Where should enterprises host their AI agents? The best platform depends on what the agent needs to do and how much infrastructure your team wants to manage. - **Northflank:** Best for enterprises that need application infrastructure, secure sandboxes, GPUs, databases, networking, and enterprise governance in one platform. - **AWS:** Best for enterprises already invested in AWS that want deep integration with its AI and cloud services. - **Google Cloud:** Best for GCP-native teams that want agents integrated with Google's AI and data infrastructure. - **Microsoft Azure:** Best for Microsoft-centric enterprises that want agents integrated with Azure and Microsoft identity and security services. - **Modal:** Best for AI workloads that need serverless GPU and compute infrastructure. - **Kubernetes or self-hosted infrastructure:** Best for enterprises that need maximum infrastructure control and have the platform engineering capacity to operate it. > **If you need more than just an agent runtime:** Look for a platform where agents, databases, application services, GPUs, and secure execution environments can run through the same control plane. [Northflank](https://northflank.com) combines these capabilities with [enterprise governance](https://northflank.com/enterprise) and self-serve [BYOC](https://northflank.com/product/bring-your-own-cloud), allowing teams to run AI agents on managed infrastructure or in their own cloud and private environments. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > AI agents can be hosted in many places, from hyperscaler infrastructure and application platforms to specialized AI compute and enterprise-owned environments. Choosing where an agent runs, however, is about more than finding the right compute or model access. The right platform depends on what the agent actually needs to run reliably in production. An agent that calls external models and a few internal APIs has very different requirements from one that executes code, runs local models, or handles sensitive enterprise data. This guide compares the leading platforms for hosting enterprise AI agents and what to consider when choosing between them. ## Where does an AI agent actually run? An AI agent is usually an application made up of several components rather than a single process. The agent runtime might run as a container, serverless workload, Kubernetes service, virtual machine, or isolated sandbox, while databases, queues, object storage, model APIs, and other services run alongside it. The execution environment becomes particularly important when an agent can execute code, access files, call internal APIs, or use credentials to take actions. An agent that only calls an external model API may run comfortably as a standard application, while an agent executing untrusted code needs a stronger isolation boundary. Enterprises should therefore evaluate both **where the agent runs and what infrastructure it needs around it**. A production agent may need databases, background workers, scheduled jobs, GPUs, private networking, secrets management, and isolated execution in addition to its core runtime. ## **What determines where an enterprise should host its AI agents?** The right hosting platform depends on the agent's requirements and the organization's existing infrastructure. Evaluate these factors before choosing a platform: - **Data and compliance:** What data can the agent access, and where must that data remain? Agents handling sensitive or regulated data may require specific regions, private infrastructure, or customer-controlled cloud environments. - **Runtime and isolation:** Does the agent only call APIs, or does it execute generated code, shell commands, access files, or interact with untrusted packages? Higher-risk execution requires stronger isolation. - **Compute and GPUs:** Agents using hosted models may primarily need CPU infrastructure, while agents running local models or inference workloads may require GPUs. - **Application infrastructure:** Does the agent need databases, queues, object storage, background workers, scheduled jobs, or persistent volumes? - **Networking:** Does the agent need access to private databases, internal APIs, or external services? Look for private networking and controls over ingress and egress. - **Enterprise security:** Look for SSO, RBAC, secrets management, scoped access, audit logs, and controls that separate developers, automation, and production workloads. - **Deployment and operations:** Production agents need repeatable deployments, health checks, observability, scaling, rollback, and backup capabilities. - **Infrastructure flexibility:** Enterprises may need managed infrastructure, BYOC, multiple cloud providers, or self-hosted environments depending on their requirements. - **Operational capacity:** A managed platform reduces the infrastructure your team needs to operate, while Kubernetes and bare-metal deployments provide more control at the cost of additional operational work. The right platform is the one that meets the agent's actual requirements without forcing the enterprise to operate infrastructure it does not need. ## Best platforms for hosting enterprise AI agents There is no single platform that is best for every enterprise AI agent. The platforms below take different approaches, from full-stack application platforms to hyperscaler infrastructure and specialized AI compute. ### 1. Northflank [Northflank](https://northflank.com/) is a full-stack application platform for running AI agents and the infrastructure around them. It combines secure agent sandboxes, GPU workloads, managed databases, CI/CD, preview environments, networking, and enterprise governance in a single control plane. Teams can run workloads on [Northflank Managed Cloud](https://northflank.com/features/managed-cloud) or deploy into their own infrastructure through [self-serve BYOC](https://northflank.com/product/bring-your-own-cloud). **Key features:** - [**Sandbox isolation**](https://northflank.com/product/sandboxes): Securely execute untrusted or AI-generated code in isolated environments using Kata Containers with Cloud Hypervisor, Firecracker, or gVisor, depending on the workload and infrastructure. - [**GPU workloads**](https://northflank.com/product/gpu-paas): Run AI training, inference, batch jobs, and agent workloads on H100, H200, A100, L4, L40S, and B200 GPUs alongside CPU services, sandboxes, and managed databases. - [**Managed databases**](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank): Provision PostgreSQL, MySQL, MongoDB, Redis, MinIO, and RabbitMQ with automated backups, point-in-time recovery, and database instances for preview environments. - [**CI/CD and preview environments**](https://northflank.com/product/preview-environments): Deploy from Git repositories with automated builds, deployment workflows, and isolated preview environments for testing agent applications and their dependencies. - [**Enterprise controls**](https://northflank.com/docs/v1/application/enterprise): Secure workloads with [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [SAML and OIDC SSO](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication), [secrets management](https://northflank.com/docs/v1/application/secure/security-on-northflank#secret-management), and [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) that integrate with SIEM platforms. - [**BYOC**](https://northflank.com/product/bring-your-own-cloud) **and** [**forward-deployed deployments**](https://northflank.com/enterprise): Run workloads in customer-controlled cloud, private, or on-premises infrastructure, with forward-deployed options for organizations that require the platform to run entirely within their own environment. - [**Northflank Skills**](https://github.com/northflank/skills): Deploy, manage, troubleshoot, and scale workloads directly from AI coding agents such as Claude Code, Codex, Gemini CLI, and Cursor. Northflank also supports the wider application stack around an agent, including networking, secrets, observability, deployment workflows, and supporting infrastructure. This means teams can run the agent and the services it depends on through the same platform instead of assembling separate infrastructure for each part of the workload. **Best for:** Enterprise AI agent hosting, regulated workloads, agents that execute code, and teams that need GPUs, secure sandboxes, managed infrastructure, and flexible deployment options in one platform. [Get started on Northflank](https://northflank.com/) or [book a demo with an engineer](https://cal.com/team/northflank/northflank-demo) to see if the platform fits your agent infrastructure requirements. ### 2. Amazon Web Services Amazon Web Services provides several ways to run AI agents, including managed AI services, containers, serverless compute, Kubernetes, and GPU infrastructure. Teams can build agents with services such as Amazon Bedrock and run supporting workloads using ECS, EKS, databases, queues, and object storage. The main advantage is breadth and integration. Enterprises already invested in AWS can build agents directly into their existing identity, networking, security, observability, and infrastructure architecture. The tradeoff is that assembling a complete agent platform from individual AWS services can require significant expertise across multiple infrastructure layers. **Best for:** Enterprises already standardized on AWS that want to build and operate AI agents directly within their existing cloud architecture. ### 3. Google Cloud Google Cloud combines managed AI and agent capabilities with its broader cloud infrastructure, including compute, GPUs, databases, networking, IAM, and data services. This gives enterprises multiple options for building and running agents while keeping them close to their existing cloud and data infrastructure. Google Cloud is particularly suited to organizations already using Google Cloud for data, analytics, and machine learning workloads. Its broader AI platform also provides managed capabilities for teams that do not want to assemble the entire agent stack themselves. **Best for:** Google Cloud enterprises that want AI agents closely integrated with their existing AI, data, and cloud infrastructure. ### 4. Microsoft Azure Microsoft Azure provides managed AI and agent capabilities alongside containers, Kubernetes, GPUs, databases, networking, and Microsoft identity infrastructure. Enterprises can combine these services to build agents that integrate with their existing Azure environment. Azure is particularly attractive to organizations already invested in Microsoft 365, Entra ID, Azure infrastructure, and the wider Microsoft enterprise ecosystem. Its broad compliance portfolio can also make it suitable for organizations with strict regulatory and governance requirements. **Best for:** Microsoft-centric enterprises that want AI agents integrated with their existing Azure and identity infrastructure. ### 5. Modal Modal is a serverless compute platform focused on AI and machine learning workloads. It provides on-demand CPU and GPU compute with a Python-first development model, allowing teams to run workloads without managing traditional servers or Kubernetes infrastructure. For AI agents that need GPU acceleration, model inference, or bursty compute, Modal provides a specialized infrastructure layer with a relatively simple developer experience. **Best for:** AI teams building Python-based agents that need scalable serverless CPU and GPU infrastructure. ### 6. Kubernetes and self-hosted infrastructure Enterprises can run AI agents directly on Kubernetes, private Kubernetes distributions, or bare-metal infrastructure. This provides extensive control over the execution environment, networking, data location, security policies, and underlying infrastructure. The tradeoff is operational complexity. Kubernetes provides orchestration, but enterprises still need to provide or integrate CI/CD, secrets management, observability, databases, networking, access controls, sandboxing, and other platform capabilities required to operate agents reliably. **Best for:** Enterprises with existing platform engineering teams, strict infrastructure requirements, or workloads that cannot run on managed platforms. ## How to choose the right AI agent hosting platform The best platform depends on which requirements matter most for your workloads. | Requirement | Best option | Why | | --- | --- | --- | | Full-stack AI agent infrastructure | **Northflank** | Agents, services, databases, jobs, GPUs, sandboxes, networking, and governance in one platform | | Existing AWS investment | AWS | Deep integration with AWS infrastructure and AI services | | Existing Google Cloud investment | Google Cloud | Strong integration with Google's AI and data ecosystem | | Existing Microsoft investment | Azure | Deep integration with Azure, Microsoft identity, and enterprise services | | Serverless GPU workloads | Modal | Specialized GPU and compute infrastructure | | Multi-cloud or BYOC requirements | **Northflank** | Consistent platform across managed cloud and customer cloud infrastructure | | Maximum infrastructure control | Kubernetes / self-hosted | Full control over the underlying environment | For enterprises running a small number of conventional agents, a hyperscaler or application platform may be enough. For specialized GPU workloads, a platform such as Modal can make more sense. Organizations with significant existing platform engineering capacity may prefer Kubernetes when maximum infrastructure control is more important than operational simplicity. **Northflank is the strongest overall option when an enterprise needs more than an agent runtime.** It combines application infrastructure, databases, GPUs, secure sandbox execution, networking, CI/CD, and enterprise governance in one self-serve platform. It can also run on Northflank's managed cloud or in customer-controlled infrastructure, giving enterprises flexibility as requirements change. This is particularly useful for enterprises running different types of agents, where some workloads need standard application infrastructure while others require GPUs, databases, private networking, or isolated code execution. ## FAQ: where should enterprises host their AI agents? ### Can enterprises host AI agents in their own cloud? Yes. Platforms that support BYOC can run agent workloads inside an enterprise's AWS, Azure, GCP, or other supported cloud environment. This can provide greater control over networking, data residency, and infrastructure while retaining a managed application platform. ### Do AI agents need dedicated infrastructure? Not necessarily. Agents that primarily call external model APIs can often run on standard application infrastructure. Dedicated GPUs or specialized execution environments become more important when agents run local models, execute code, or require stronger isolation. ### Do AI agents need sandboxing? Not every agent needs a dedicated sandbox. Agents that execute generated code, user-submitted code, shell commands, or untrusted packages need an appropriate isolation boundary. Conventional agents that only call APIs and access trusted services can often run using standard application isolation. ### Should enterprises use a managed platform or build their own? Managed platforms generally reduce operational overhead and provide a faster path to production, while self-hosted infrastructure provides more control. The right choice depends on the organization's security requirements, existing infrastructure, platform engineering capacity, and number of agent workloads. ### Can enterprises use multiple platforms for their AI agents? Yes. Enterprises may use different platforms for different workloads. The important consideration is maintaining consistent identity, security, networking, deployment, and audit controls across the environments where agents run. ## Conclusion There is no single best place to host an enterprise AI agent. The right platform depends on the agent's runtime behavior, data requirements, compute needs, existing cloud infrastructure, security requirements, and the operational capacity of the team running it. For enterprises running a growing portfolio of agents, the platform matters as much as the underlying infrastructure. A platform that combines application hosting, secure execution, GPUs, databases, networking, deployment workflows, and enterprise governance gives teams a consistent way to move agents from development into production. [Get started with Northflank](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to explore an enterprise AI agent hosting architecture. ## Related articles - [Best platforms to host AI agents](https://northflank.com/blog/best-platforms-to-host-ai-agents) - [What is BYOC in cloud computing?](https://northflank.com/blog/what-is-byoc-in-cloud-computing?utm_source=chatgpt.com) - [How to secure AI agents in the cloud](https://northflank.com/blog/how-to-secure-ai-agents-in-the-cloud) - [How to manage enterprise AI infrastructure](https://northflank.com/blog/how-to-manage-enterprise-ai-infrastructure)

Best platforms for high concurrency sandbox environments in 2026

2026-08-13T14:00:00.000Z

## TL;DR: Best platforms for high concurrency sandbox environments in 2026 The best platform for high concurrency sandboxes depends on how many environments your AI agents need at once, how quickly new sandboxes must become ready, and what each workload runs. 1. **Northflank: Best for AI agent sandbox execution at high concurrency.** A fit for teams that need fast, isolated code execution across thousands of sandboxes, with custom environments for coding agents, APIs, scripts, and GPU tasks. 2. **Modal: Best for parallel sandbox workloads with GPU access.** A fit for teams that want programmatic environment creation and compute scaling, with concurrency allowances that depend on the plan. 3. **E2B: Best for agent-oriented execution with expandable concurrency.** A fit for teams that want Python or TypeScript SDKs, Firecracker isolation, and options to increase concurrent sandbox capacity as demand grows. 4. **CodeSandbox: Best for parallel agent runs from shared environment state.** A fit for teams that use snapshots and forks to give agents separate copies of a prepared coding environment. 5. **Fly.io Sprites: Best for pools of persistent agent environments.** A fit for teams whose agents return to saved files between tasks, with automatic idle behavior and on-demand wake-up. Follow the [Northflank sandbox quickstart](https://northflank.com/docs/v1/application/sandboxes/quickstart) to run your first agent workload, or [talk to an engineer](https://cal.com/team/northflank/northflank-demo?duration=30) about scaling concurrent sandbox execution. ## Why concurrency is the hard problem in sandbox infrastructure Spinning up a single isolated sandbox is straightforward. The hard part is what happens at scale: thousands of agents running in parallel, each needing its own environment, sufficient resources, and a reliable way to clean up after execution. Rate limits, provisioning queues, image downloads, and available compute can all affect how quickly a new sandbox becomes usable. A platform that handles a small development workload needs to be tested against the bursts and sustained load your production agents will generate. Keep three measurements separate: **live concurrency** is the number of sandboxes running at once, **creation rate** is how many new environments can start in a given period, and **startup latency** is how long each takes to become usable. Millions of executions per month do not establish a simultaneous concurrency limit. Evaluate those measurements alongside isolation, resource allocation, autoscaling behavior, and the cost of keeping capacity available. ## What are the best platforms for high-concurrency sandboxes? The platforms below support different patterns of parallel agent execution. Compare their concurrency allowances, provisioning behavior, supported workloads, and deployment options against your expected traffic. ### 1. Northflank [Northflank](https://northflank.com/product/sandboxes) provides isolated sandbox environments for AI agents and code execution, with fast startup and support for thousands of concurrent sessions. Run coding agents, generated APIs, scripts, repository builds, and GPU tasks in custom container environments, with persistent volumes when files need to survive between runs. ![northflank-sandbox-page.png](https://assets.northflank.com/northflank_sandbox_page_dd9fa07375.png) Northflank combines API-driven sandbox provisioning with horizontal scaling and workload scheduling to support parallel execution. Create separate environments for users or tasks, configure compute and networking, and run ephemeral or persistent sandboxes on Northflank Cloud or your own infrastructure. **Key features:** - **Concurrent sandbox execution:** Run thousands of isolated environments for parallel agent tasks, code evaluation, and multi-tenant workloads. - **Horizontal autoscaling:** Configure minimum and maximum deployment instance counts and scaling thresholds for CPU, memory, or requests per second. Create distinct per-task sandboxes through the API when each agent needs its own environment. - **Workload scheduling:** Bin-packing places workloads across available compute to improve resource utilization while maintaining their isolation boundaries. - **Fast startup:** Sub-second sandbox boot times on Northflank Cloud for quickly provisioning execution environments. - **Isolation:** Northflank Cloud uses microVMs for CPU sandboxes and gVisor for GPU sandboxes, with isolation enabled automatically. - **Custom environments:** Deploy container images from public or private registries for coding agents, APIs, scripts, test suites, and GPU tasks. - **Persistence and duration:** Use ephemeral environments for disposable runs or attach volumes for files that must survive pauses and restarts. Sandboxes have no fixed session time limit. - **Managed cloud or bring your own cloud (BYOC):** Run on Northflank Cloud or your own infrastructure. With bring your own cloud (BYOC), Northflank acts as the control plane to run coding agents and their sandboxes in your virtual private cloud (VPC). - **Security:** Northflank is [SOC 2 Type II and HIPAA compliant](https://northflank.com/security), with Business Associate Agreements (BAAs) supported under Enterprise contracts. [cto.new migrated its sandbox infrastructure to Northflank](https://northflank.com/blog/cto-new-uses-northflank-for-secure-sandboxes) in a couple of days after scaling on EC2 metal instances caused large capacity and cost jumps. The team went on to run thousands of daily container deployments with API-driven provisioning and per-second billing. **Best for:** Teams running thousands of concurrent AI agent sandboxes, multi-tenant code execution, and parallel workloads that need custom images, persistent files, or GPUs. **Pricing:** $0.01667/vCPU-hour and $0.00833/GB-hour, with H100 GPU plans at $2.74/hour all-inclusive (CPU and RAM included). The free developer Sandbox tier offers always-on compute with no sleeping, two free services, one database, and two cron jobs for development and testing. Pay-as-you-go supports CPU and GPU workloads with per-second billing. Enterprise plans provide custom pricing, 24/7 support, service-level agreements (SLAs), and enterprise access controls. [See the full pricing details](https://northflank.com/pricing) for additional GPU options and plans. [Get started on Northflank](https://app.northflank.com/signup) to run isolated AI agent sandboxes, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) with an engineer to discuss your workload's concurrency and startup requirements. ### 2. Modal Modal supports parallel sandbox execution with programmatic resource allocation and GPU access. Its pricing plans list 100 containers on Starter and 5,000 on Team, with custom Enterprise capacity. GPU concurrency is a separate allowance: 10 on Starter and 50 on Team. Standard sandboxes use gVisor, while CPU-only VM Sandboxes are available in beta. Python, JavaScript, and Go clients support environment creation, including existing container images. For high concurrency workloads, size CPU and memory requests around the work each sandbox performs and test how creation bursts behave at your account's limits. **Best for:** Parallel agent tasks, ML evaluations, and compute-heavy workloads that need GPUs and programmatic environment configuration. **Pricing:** Starter has no subscription fee and includes $30/month in compute credits. Team costs $250/month plus compute, with $100/month in included compute. Sandbox CPU costs $0.1419/physical-core-hour and memory costs $0.0240/GiB-hour. ### 3. E2B E2B provides Firecracker-isolated sandboxes with Python and TypeScript SDKs for creating environments, executing code, and managing files. Hobby supports 20 concurrent sandboxes. Pro includes 100, with paid add-ons that expand the allowance to 600 or 1,100. Enterprise supports custom higher concurrency. For parallel agents, check both the number of active sandboxes and how quickly you can create new ones. Bring your own cloud (BYOC) is available on Enterprise for AWS, GCP, and Azure. **Best for:** Coding agents, evaluation pipelines, and Code Interpreter-style tools that need SDK integration and configurable concurrency capacity. **Pricing:** Hobby includes a $100 one-time usage credit. Pro starts at $150/month plus usage; concurrency add-ons cost extra. Enterprise pricing is custom. ### 4. CodeSandbox CodeSandbox supports fork and snapshot workflows for parallel agent execution. Create a prepared environment, then give separate agents their own copies of its state. This reduces repeated setup work when many tasks need the same dependencies and repository configuration. CodeSandbox is part of Together AI and supports Docker and Dev Container customization. Build allows 10 concurrent VM sandboxes; Scale allows 250, with custom Enterprise limits. Scale also allows 1,000 new SDK sandboxes per hour, which is a separate limit from how many can run simultaneously. **Best for:** Parallel agent runs from shared state, testing alternative code changes, and coding tools that need reproducible starting environments. **Pricing:** Build is free. Scale starts at $170 per workspace per month, with included VM credits and additional usage charges. CPU and memory are bundled into VM tiers; Enterprise pricing is custom. ### 5. Fly.io Sprites Fly.io Sprites provide persistent Linux environments that pause when inactive and wake when needed. This supports pools of agent environments where each user or task retains files, packages, and repository changes between executions. A warm wake resumes frozen processes in 100–500 ms. After a cold transition, waking takes 1–2 seconds and processes start fresh, while files remain available. These are wake timings, not measurements of creating thousands of new environments simultaneously. For a large pool, distinguish the number of retained Sprites from the number actively executing work. Test simultaneous wake-ups and sustained resource usage against the capacity available to your organization. Persistence alone does not establish a low or high concurrency ceiling. **Best for:** Persistent agent environments with uneven activity, where automatic idle behavior reduces active compute time between tasks. **Pricing:** Through September 30, 2026, CPU costs $0.07/CPU-hour and memory costs $0.04375/GB-hour. From October 1, the rates are $0.03825/CPU-hour and $0.021875/GB-hour. Idle compute is free; retained cold storage is billed. ## Which platform should you choose for high-concurrency sandboxes? Northflank is a strong fit for teams that need fast, isolated sandbox execution across thousands of concurrent AI agent environments, with custom images, persistent files, GPU access, and optional deployment in their own infrastructure. Modal fits programmatic parallel workloads and GPU execution. E2B offers SDK-driven execution with expandable plan allowances. CodeSandbox suits parallel runs from shared environment state, while Sprites suits persistent environments that pause between tasks. Use the table to distinguish capacity allowances from startup behavior. Boot, snapshot restore, and waking an existing environment measure different lifecycle steps. | Platform | Concurrency and scaling | Startup and resume | Bring your own cloud (BYOC) | Isolation | | --- | --- | --- | --- | --- | | **Northflank** | Thousands of concurrent sandboxes; API-driven provisioning and horizontal scaling | Sub-second sandbox boot on Northflank Cloud | Yes, self-serve | MicroVMs for CPU and gVisor for GPU on Northflank Cloud | | **Modal** | 100 containers Starter; 5,000 Team; custom Enterprise; separate GPU allowances | Creates environments from images; supports snapshots | No | gVisor; CPU-only VM option in beta | | **E2B** | 20 Hobby; 100 Pro, expandable to 1,100; custom Enterprise | Template-based creation and pause/resume | AWS, GCP, and Azure on Enterprise | Firecracker | | **CodeSandbox** | 10 VM sandboxes Build; 250 Scale; custom Enterprise | Snapshot restore and environment cloning | No | MicroVMs | | **Fly.io Sprites** | Persistent environment pools; size and test active capacity for your workload | Warm wake: 100–500 ms; cold wake: 1–2 seconds | No | Firecracker | ### How do high-concurrency sandbox platforms compare on pricing? Pricing checked on September 30, 2026. Hourly equivalents are rounded where needed. The table shows usage rates; subscription fees and included allowances vary by plan. | Platform | CPU | Memory | Storage | GPU | Billing model | | --- | --- | --- | --- | --- | --- | | **Northflank** | $0.01667/vCPU-hr | $0.00833/GB-hr | $0.15/GB-month | L4: $0.80/hr, A100 40GB: $1.42/hr, A100 80GB: $1.76/hr, H100: $2.74/hr | Per second | | **E2B** | $0.0504/vCPU-hr | $0.0162/GiB-hr | 10 GiB Hobby / 20 GiB Pro included | No GPU compute | Per second; Pro adds $150/month plus usage | | **Fly.io Sprites** | $0.07/CPU-hr through Sept. 30; $0.03825 from Oct. 1 | $0.04375/GB-hr through Sept. 30; $0.021875 from Oct. 1 | $0.000683/GB-hr hot; $0.000027/GB-hr cold | No GPU compute | Actual usage, metered hourly; idle compute is free, retained cold storage is billed | | **CodeSandbox** | Pico VM: $0.075/VM-hr (1 core and 2 GB RAM) | Included in VM price | Plan-dependent; 20 GB per VM on standard plans | No GPU compute | VM credits; subscription and included credits depend on plan | | **Modal Sandboxes** | $0.1419/physical-core-hr (2 vCPU) | $0.0240/GiB-hr | Volumes: $0.09/GiB-month; 1 TiB/month included | L4: $0.80/hr, A100 40GB: $2.10/hr, A100 80GB: $2.50/hr, H100: $3.95/hr, H200: $4.54/hr | Per second | Billing units differ: CodeSandbox includes CPU and RAM in its VM price, while Modal charges per physical core (two vCPUs). The CodeSandbox VM rate is before subscription savings. ### Bring your own cloud (BYOC) support across high-concurrency sandbox platforms The table below shows how each platform handles bring your own cloud (BYOC) deployment, which clouds are supported, and whether it requires a sales process. | Platform | Bring your own cloud (BYOC) available | Clouds supported | Access model | Pricing model | | --- | --- | --- | --- | --- | | **Northflank** | Yes, self-serve | AWS, GCP, Azure, Oracle, CoreWeave, Civo, and supported Kubernetes infrastructure, including on-premises and bare-metal | Self-serve; Enterprise contracts available | Cloud infrastructure costs plus Northflank management charges | | **E2B** | Yes, Enterprise | AWS, GCP, and Azure | Contact sales | Custom Enterprise pricing plus cloud infrastructure costs | | **Modal** | No | Managed only | — | — | | **Fly.io Sprites** | No | Managed only | — | — | | **CodeSandbox** | No | Managed service; dedicated cluster option on Enterprise | Contact sales for dedicated clusters | Custom dedicated-cluster pricing | A dedicated cluster does not by itself mean the service runs in your cloud account. ## FAQ: high concurrency sandbox environments ### What limits sandbox concurrency on most platforms? Concurrency depends on plan allowances, API rate limits, available CPU and memory, regional capacity, and the resources each sandbox requests. Autoscaling helps provision capacity, but it does not make those constraints disappear. Check simultaneous sandbox limits and creation-rate limits separately. ### What is bin-packing, and why does it matter for concurrency? Bin-packing places workloads onto available compute to use capacity efficiently. At high concurrency, placement affects how many sandboxes fit on each node and whether new workloads must wait for additional capacity. Northflank uses bin-packing in its scheduling; resource requests and available capacity still determine how efficiently a particular workload runs. ### Does isolation quality change at high concurrency? The isolation boundary should remain consistent as concurrency increases. MicroVMs separate guest kernels, while gVisor intercepts system calls through a user-space kernel. Neither automatically eliminates contention for shared physical CPU, storage, or network resources. Resource limits, scheduling, and network policies also matter when many tenants run simultaneously. ### Which platform handles concurrent ML evaluation workloads best? Northflank and Modal are options for parallel evaluations that need GPU access. Northflank supports custom sandbox images, concurrent CPU and GPU workloads, and execution in your own infrastructure. Modal provides programmatic environments and GPU allocation. Compare available GPU capacity, task throughput, and cost using your actual evaluation workload. ### Can I run concurrent sandboxes in my own cloud? Yes. Northflank offers self-serve bring your own cloud (BYOC), acting as the control plane to run coding agents and their sandboxes in your virtual private cloud (VPC). E2B also supports bring your own cloud (BYOC) on AWS, GCP, and Azure through Enterprise. Available capacity and supported isolation runtimes depend on the deployment. ### How does cold start speed affect high concurrency workloads? Startup latency affects how quickly agents can begin work, while creation throughput determines how fast a batch of environments can become available. Under burst load, measure readiness latency, queued requests, and failures together. Northflank Cloud offers sub-second sandbox boot times; test the complete workload at your target concurrency to understand when agents can begin executing tasks. ## Conclusion High concurrency sandbox infrastructure needs to handle both the environments already running and the next wave of requests. Compare live capacity, creation rates, startup latency, and workload isolation separately. Northflank combines fast sandbox startup, thousands of concurrent sessions, custom container environments, and CPU or GPU execution. It is a strong starting point for teams running coding agents, generated APIs, scripts, and evaluation tasks at scale, on managed infrastructure or inside their own cloud. [Get started on Northflank](https://app.northflank.com/signup) or [talk to the team](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your concurrent sandbox workloads.

How to run millions of concurrent AI sandboxes

2026-08-12T15:59:00.000Z

Running AI sandboxes at scale means handling demand without weakening isolation or causing a fleet-wide failure. One million live environments, daily starts, and mostly paused workspaces are different targets. This guide covers architecture, capacity, isolation, burst performance, operations, observability, and Northflank. ## TL;DR: How to run millions of concurrent AI sandboxes Run millions of concurrent AI sandboxes by splitting the fleet into bounded regional cells, then routing each accepted request to a scheduler inside one cell. - Avoid putting the entire million-sandbox execution fleet into one Kubernetes control plane. Shard execution across independently recoverable cells. - Separate admission from placement. The global layer enforces identity, policy, quota, and regional routing; each cell chooses a host. - Make lifecycle changes retry-safe so controllers can finish them after clients disconnect. - Size ready headroom for net concurrency growth and infrastructure lead time, not average concurrency. Measure time to interactive rather than hypervisor boot alone. - Match isolation, networking, credentials, storage, and telemetry to the threat model. At this scale, cleanup and containment are core platform features. If your enterprise needs to run many untrusted AI-generated workloads with controlled isolation, lifecycle, networking, and infrastructure placement, [Northflank Sandboxes](https://northflank.com/product/sandboxes) provide ephemeral or persistent execution environments for agent-generated code, shell commands, dependencies, and user-submitted code. Northflank has run millions of microVMs per month since 2021. Run on [Northflank Cloud](https://northflank.com/cloud/northflank) or use self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud) to place sandbox workloads in your cloud account. [Northflank Skills](https://github.com/northflank/skills) helps supported coding agents operate sandboxes and the surrounding stack through the Northflank API and CLI, within the credentials and permissions you assign. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or scale requirements. ## What does “millions of concurrent AI sandboxes” mean? Millions of concurrent AI sandboxes means millions of isolated execution environments are live and consuming runtime capacity at the same time. It does not mean millions of sandbox starts, paused environments, or completed executions over a day or month. Define four service-level measures before choosing an architecture: - **Live concurrency:** sandboxes consuming runtime resources now. - **Start throughput:** new environments admitted per second during a burst. - **Time to interactive:** time from an accepted request until the workload can execute useful work. - **Lifecycle volume:** environments created, resumed, paused, and destroyed over a day or month. A coding workspace may run for hours, while a reinforcement-learning rollout resets every few seconds. An environment can retain files without consuming compute. As a simplified example, if each live sandbox reserves 256 MiB of memory, one million sandboxes require about 244 TiB of guest memory before runtime and host overhead. Both the management layer and compute fleet must scale. ## Why can’t one Kubernetes cluster run millions of AI sandboxes? A conventional one-pod-per-sandbox design cannot fit one million live AI sandboxes inside [Kubernetes' current large-cluster design envelope](https://kubernetes.io/docs/setup/best-practices/cluster-large/) of 5,000 nodes and 150,000 total pods. One million pods exceed it more than six times over. Creates, status updates, reschedules, and deletes also pressure the control plane, the components that schedule and manage workloads. Use multiple cells instead. A cell is a bounded unit of clusters or hosts with its own scheduling capacity and failure radius. The global platform tracks which cells can accept work, while detailed sandbox state stays local. For a build-or-buy decision, compare [high-concurrency sandbox platforms](https://northflank.com/blog/best-platforms-for-high-concurrency-sandbox-environments) by isolation, lifecycle, deployment, and production-stack support. ## What architecture supports millions of live AI sandboxes? A cell-based architecture can support millions of live AI sandboxes by separating global request acceptance and regional routing from scheduling and execution inside each cell. Each layer holds only the state required for its decision. ### 1. Global admission and routing The admission service decides whether to accept a request. It authenticates the caller, checks tenant policy and quota, selects an eligible region and cell, then returns a sandbox ID that remains stable across retries. When no eligible cell has safe capacity, queue bounded work or reject it with a retry signal. Use idempotency keys to prevent duplicate environments. ### 2. Regional cells with local schedulers Each cell chooses a host, starts the runtime, configures networking, and restores unhealthy workloads. Maintain separate resource pools and spread workloads across hosts and availability zones. If workload location and cloud ownership are requirements, [Northflank BYOC sandbox clusters](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-in-your-cloud) run sandbox workloads on microVM-enabled node pools in your cloud account. Runtime availability depends on the cloud provider and region. ### 3. An asynchronous lifecycle reconciler Treat a sandbox as a requested outcome rather than one long-running API connection. A lifecycle controller records what should exist and moves the sandbox through accepted, starting, ready, paused, terminating, and deleted states. Expiry leases remove abandoned sandboxes. Cleanup controllers remove runtime, network, credential, and storage attachments, while final deletion records prevent late events from recreating an environment. The [Northflank sandbox lifecycle documentation](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) covers asynchronous startup, status checks, command execution, pause, resume, and deletion through the JavaScript SDK. Your application can use these operations to manage each sandbox. ### 4. A runtime and isolation layer Choose isolation from the workload's trust level. Containers share the host kernel and may suit trusted internal code when your risk model accepts that boundary. gVisor moves much of the system-call interface into a user-space kernel, reducing direct exposure to the host kernel. It is not a microVM. Hardware-virtualized options such as Firecracker or VM-backed Kata Containers give the guest a separate kernel boundary, usually at a higher resource cost. A minimal [Firecracker test VM](https://github.com/firecracker-microvm/firecracker/blob/main/SPECIFICATION.md) with 1 vCPU and 128 MiB of memory takes no more than 125 ms from its start API call to guest init, with no more than 5 MiB of VMM thread overhead. Full readiness also depends on networking, storage, credentials, and process startup. [Northflank Sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) use hardware-virtualized microVM isolation or gVisor user-space-kernel isolation depending on the workload and infrastructure. Runtime availability varies by cloud, region, and hardware. ### 5. External state, networking, and identity Prefer disposable root filesystems. Put durable files on volumes or object storage, and keep orchestration state outside the runtime. Immutable images and copy-on-write roots make replacement predictable. Do not allocate a public IP or load balancer to every sandbox. Route through shared regional gateways. Default-deny east-west traffic, apply per-task egress policy, and issue short-lived credentials. Northflank [persistent volumes](https://northflank.com/docs/v1/application/databases-and-persistence/add-a-volume) preserve files across restarts, while [private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank#private-networking) connects internal workloads without public exposure. On BYOC clusters, [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies) control ingress (inbound traffic) and egress (outbound traffic) between workloads and projects. ## How do you plan capacity and burst performance for millions of AI sandboxes? Plan capacity and burst performance by load testing one cell, calculating the active and failover capacity your target requires, and keeping enough ready infrastructure for sudden growth. As a simplified example, if one tested cell safely supports 25,000 live sandboxes, one million live sandboxes require 40 active cells. Add separate capacity for the largest failure your architecture must absorb, such as losing a region. Size hosts independently for CPU, memory, storage IOPS, and network throughput. Keep ready hosts, images, filesystems, and network capacity outside the startup path. Measure time to interactive from request acceptance through scheduling, image preparation, networking, credentials, process startup, and health checks. Track median and tail latency, start failures, live concurrency, available capacity, and cleanup lag by region, cell, runtime, and workload class. These are starting estimates; workload-specific load tests determine safe limits. ## How do you secure a multi-tenant AI sandbox fleet? Secure a multi-tenant AI sandbox fleet with layered identity, runtime isolation, network policy, short-lived credentials, resource limits, and independent incident controls. Authenticate every lifecycle and command-execution request, bind it to a tenant, and authorize it before routing into a cell. Inside the runtime, drop unnecessary privileges and devices, enforce CPU, memory, process, and disk limits, and terminate workloads that violate policy. For untrusted multi-tenant workloads, default-deny sandbox-to-sandbox networking unless explicitly required. Restrict egress destinations, protocols, and rates to reduce exfiltration and abuse. Scope credentials to the task and expire them automatically. Independent controls must terminate runs, revoke credentials, block egress, quarantine state, and stop further requests. Confirm that compute, routes, credentials, and temporary data are gone. Northflank [secret injection](https://northflank.com/docs/v1/application/secure/inject-secrets) supplies selected workloads with stored credentials, and [scoped API access](https://northflank.com/docs/v1/application/secure/grant-api-access) applies permissions through an associated RBAC role. Your application or authorization layer remains responsible for deciding which tenant data and agent tools each sandbox may access. ## How can Northflank run AI sandboxes at scale? Northflank runs AI sandboxes at scale by combining isolated execution, API-driven lifecycle management, persistence, networking, governance, and the surrounding application stack on one platform. - **Sandbox lifecycle and isolation:** [Northflank sandbox documentation](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) covers create, status, command execution, pause, resume, persistence, and deletion. Workloads use hardware-virtualized microVM or gVisor user-space-kernel isolation depending on the workload and infrastructure. - **Infrastructure placement:** Use [Northflank Cloud](https://northflank.com/cloud/northflank) for managed infrastructure or [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud) to run the sandbox runtime, storage, networking, and workload data path in your cloud account. Northflank-hosted control-plane metadata remains outside that workload data plane; review configuration-dependent flows such as logs, builds, images, DNS, and backups separately. - **Identity and governance:** [SAML or OIDC SSO](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation#configure-single-sign-on-sso), [directory sync](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation#sync-your-directory), [MFA enforcement](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation#manage-organisation-security), [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [scoped API access](https://northflank.com/docs/v1/application/secure/grant-api-access), and [secret injection](https://northflank.com/docs/v1/application/secure/inject-secrets) separate access for your teams and workloads. [Audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) record platform events and affected resources. Your application still owns tenant and task authorization. - **Agent-native operations:** [Northflank Skills](https://github.com/northflank/skills) helps supported coding agents operate sandboxes and the surrounding services, databases, GPU workloads, previews, and releases through the Northflank API and CLI. The agent's assigned credentials and permissions still govern access. - **Compliance:** Northflank is SOC 2 Type 2 compliant and HIPAA compliant, with BAAs supported under Enterprise contracts. [See Northflank security details](https://northflank.com/security). - **Demonstrated scale:** [Northflank](https://northflank.com/product/sandboxes) has run millions of microVMs monthly since 2021. In [ComputeSDK's 18 June 2026 burst test](https://platform.computesdk.com/scale-invitational), Northflank reached 100,000 concurrent live CPU sandboxes from cold start in 24 seconds. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or scale requirements. ## Frequently asked questions about concurrent AI sandboxes These FAQs answer implementation questions. ### Can one Kubernetes cluster run one million AI sandboxes? A single conventional Kubernetes cluster cannot run one million one-pod-per-sandbox environments inside its 150,000-pod design envelope. Use multiple cells. ### Do all AI sandboxes need microVM isolation? It depends on the workload and threat model. Trusted internal workloads may accept ordinary container isolation, while untrusted user-submitted or model-generated code usually warrants a hardware-backed microVM or appropriate user-space-kernel boundary, plus network, credential, and resource controls. [Northflank Sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) use hardware-virtualized microVM or gVisor user-space-kernel isolation depending on the workload and infrastructure. ### How much warm capacity should a sandbox platform keep? Keep enough ready capacity to absorb the net increase in live sandboxes while new infrastructure is being provisioned, plus capacity for failures. For a worst-case burst in which no sandboxes finish, use the peak start rate; load tests determine the final reserve. ### Is fast microVM boot the same as fast sandbox startup? No, fast microVM boot is not the same as fast sandbox startup. Boot excludes request acceptance, queueing, placement, images, networking, storage, credentials, process startup, and health checks. In [ComputeSDK's burst test](https://platform.computesdk.com/scale-invitational) on 18 June 2026, Northflank reached 100,000 concurrent live sandboxes from cold start in 24 seconds. ## Related articles to AI sandbox infrastructure - [What is sandbox infrastructure?](https://northflank.com/blog/what-is-sandbox-infrastructure) - [Best platforms for high-concurrency sandbox environments](https://northflank.com/blog/best-platforms-for-high-concurrency-sandbox-environments) - [AI sandbox pricing comparison](https://northflank.com/blog/ai-sandbox-pricing) - [Ephemeral sandbox environments](https://northflank.com/blog/ephemeral-sandbox-environments) - [Persistent sandbox environments](https://northflank.com/blog/persistent-sandbox-environment) - [Running reinforcement-learning agents in secure sandboxes](https://northflank.com/blog/reinforcement-learning-agents-in-secure-sandboxes)

How to isolate AI agents that have access to company data

2026-08-12T15:58:00.000Z

An AI agent can turn a document containing hidden malicious instructions, excessive permissions, or a stolen credential into a cross-system incident. Its security boundary includes the model, identity, retrieval path, tools, runtime, memory, network, and credentials. This guide explains AI agent isolation, its architecture, how to select and verify boundaries, and how Northflank supports managed or customer-controlled deployment. ## TL;DR: How to isolate AI agents that have access to company data Isolate an AI agent by giving it a distinct identity and a narrowly authorized path to data, then contain its execution, memory, network access, credentials, and retained evidence independently. - Authorize each request against both the permissions of whoever started the run and the agent's narrower permissions. - Put a deterministic policy and retrieval layer between the model and company systems. - Use short-lived, task-scoped credentials instead of shared keys or developer sessions. - Isolate code execution, memory, files, and network paths according to the data and action risk. - Test cross-boundary failures and maintain a separate way to stop runs and revoke access. AI agents that query internal databases, process private files, or execute code need an isolated runtime and controlled paths to company data. [Northflank](https://northflank.com/) provides microVM-backed [sandboxes](https://northflank.com/product/sandboxes), secret injection, RBAC, and audit logs for running these agents alongside the APIs, databases, jobs, and other services they use. Run on [Northflank Cloud](https://northflank.com/cloud/northflank) or use self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud) to place the agent runtime and workload data plane inside your cloud account. If your AI agents access company data, Northflank gives you infrastructure controls for isolated execution, workload identity, secrets, private networking, and audit evidence. Your application retains control of which users, tenants, records, and tools each agent is authorized to access. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## What does it mean to isolate an AI agent from company data? Isolation constrains every path by which an agent can read, retain, transform, or disclose company data. Private model hosting alone does not achieve it. A container can separate processes while the application retains an unrestricted database credential. A private model can still receive the wrong tenant's records. Agents can turn data into actions. Indirect prompt injection inside an email, document, or repository can influence retrieval or tool use, so infrastructure must limit what a manipulated agent can reach and change. The guide to [deploying agents securely in enterprises](https://northflank.com/blog/how-to-deploy-agents-securely-in-enterprises) covers the broader controls. | Boundary | What to isolate | Failure it contains | | --- | --- | --- | | Identity | User, agent, service, and session | One identity using another's permissions | | Data access | Records, fields, tenants, purposes, and environments | Retrieval beyond the task's permitted scope | | Runtime | Code, processes, files, mounts, and compute | Malicious or generated code reaching the host or another workload | | Memory | Conversation state, vectors, caches, and checkpoints | Sensitive or poisoned context leaking into later work | | Network | Internal services and external destinations | Lateral movement and data exfiltration | | Credentials and tools | Tokens, secrets, actions, and parameters | A model converting broad credentials into broad action | | Evidence and containment | Traces, decisions, revocation, and quarantine | An incident continuing without attribution or control | The aim is to make permitted paths explicit, narrow, observable, and revocable. ## What architecture keeps agent data access contained? A contained architecture makes authorization decisions outside the model and independently isolates identity, retrieval, runtime, memory, credentials, networking, and audit evidence. ### 1. Authenticate the user and agent separately Give the agent its own named workload identity instead of a developer login or shared administrator token. Record both the agent's identity and who or what started the run, such as an employee, application, or scheduled job. This lets policy evaluate access passed from a user or system to an agent. Scope the agent by task, environment, tenant, and maximum action, and make its access independently revocable. Apply the same principles used to [manage access and security for AI-built applications](https://northflank.com/blog/how-enterprises-should-manage-ownership-access-and-security-for-ai-built-apps). On Northflank BYOC, [workload identities](https://northflank.com/docs/v1/application/bring-your-own-cloud/configure-workload-identity) let services and jobs authenticate to external cloud resources using short-lived tokens instead of stored long-lived credentials. ### 2. Put a policy broker in front of company data Do not connect the model directly to a database or shared index. Put a policy service between the agent and each data source to check every retrieval or action before content enters the model context. The agent's effective access should be limited to what both the requester and agent are permitted to do, with any additional restrictions for the task. Apply tenant, project, geography, data-classification, and environment filters at query time. Preserve source-system permissions where practical instead of rebuilding them as prompt instructions. Separate read from write paths, use masked development data where possible, and minimize returned fields and records. Treat model output as a request; deterministic policy decides whether it may proceed. ### 3. Issue task-scoped credentials to tools Give each connector a credential for its specific target service and operation. Prefer short-lived tokens, restricted scopes, and workload identity where supported. For MCP integrations, follow the [current MCP authorization specification](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization): validate that tokens were issued for the MCP server as their intended resource, and do not pass a client's MCP access token through to downstream APIs. Obtain a separately scoped token for the downstream resource. Keep credentials outside prompts, tool results, repositories, logs, and images. Inject them only for approved requests and rotate them independently. Northflank workloads can use workload identities for short-lived access to external cloud resources, [secret injection](https://northflank.com/docs/v1/application/secure/inject-secrets) for credentials that must be stored, and [API tokens](https://northflank.com/docs/v1/application/secure/grant-api-access) whose permissions come from an associated RBAC role. ### 4. Run risky work in an isolated environment Use a stronger execution boundary for generated code, shell commands, dependencies, user files, or untrusted repositories. The orchestrator should not share its host, filesystem, or privileged credentials. This principle also shapes [enterprise AI remote coding environments](https://northflank.com/blog/enterprise-ai-remote-coding-environments). Start with an ephemeral environment, lifetime and resource limits, controlled mounts, and no privileged host access. Add persistence only when required. A microVM reduces reliance on the shared host kernel. Runtime isolation contains code execution but does not determine which records the agent may retrieve. [Northflank sandboxes](https://northflank.com/product/sandboxes) provide ephemeral or persistent environments for AI agents and untrusted code. The [sandbox documentation](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) describes the microVM-backed isolation boundary used for these workloads. ### 5. Separate memory and retained artifacts Treat agent memory as a data store. Histories, vector indexes, caches, files, checkpoints, and tool results can retain sensitive information after a task ends. Partition stored state by tenant and sensitivity. Define ownership, encryption, retention, deletion, and a record of where the data came from. Validate untrusted content before storing it for future runs, as part of [governing AI-built applications at scale](https://northflank.com/blog/how-enterprises-should-govern-ai-built-applications-at-scale). Northflank sandboxes can remain ephemeral or attach persistent storage when a task requires retained state, but your application must still enforce memory partitioning, retention, and deletion rules. ### 6. Restrict every network path Allow only required ingress, egress, destinations, and protocols. Use private paths internally and broker outward actions such as email, uploads, and webhooks. Protect internal address ranges and cloud metadata services. Current [MCP security guidance](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices) warns that OAuth-related URL fetching can introduce SSRF paths to internal resources and metadata endpoints. Network controls cannot fix prompt injection but can block unapproved destinations. Keep development, staging, and production on separate network and identity paths. Enforce the boundary in infrastructure, not prompts. Northflank [private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank#private-networking) connects internal workloads without exposing them publicly. On BYOC clusters, [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies) provide ingress and egress allow and deny rules between workloads and projects, including outbound rules for specified external destinations. ### 7. Correlate evidence and keep independent shutdown controls Record enough evidence to reconstruct a run without collecting unnecessary sensitive content. Correlate identities, versions, source references, tool requests, policy decisions, approvals, affected resources, results, and state changes. Log prompts and outputs only where policy permits. Correlate platform audit logs with agent traces. Operators must independently terminate runs, revoke credentials, disable connectors, block network paths, quarantine memory, and preserve evidence. [Northflank audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) record platform and configuration events, while [API tokens can be revoked](https://northflank.com/docs/v1/application/secure/grant-api-access) independently. Correlate these events with application-level agent traces, and keep run termination and memory quarantine in the agent system. ## How should you choose the isolation boundary for an AI agent? Choose an AI agent's isolation boundary based on the most sensitive data it can reach and the highest-impact action it can perform. A single pattern would under-protect production or burden low-risk retrieval. | Workload | Recommended boundary | Data pattern | | --- | --- | --- | | Read-only knowledge agent | Separate identity, permission-filtered retrieval, tenant-partitioned memory | Approved documents returned under the user's existing access | | Departmental workflow agent | Dedicated service identity, brokered tools, restricted network, scoped durable state | Department systems with explicit read and bounded-write operations | | Coding or data agent | Ephemeral isolated runtime, controlled mounts, restricted egress, short-lived credentials | Masked data by default; narrowly approved production access only when required | | High-impact production agent | Dedicated workload and data boundary, per-action policy, independent containment, complete evidence | Minimal records and operations required for a defined production task | A sandbox per run may suit untrusted code but not be necessary for a read-only assistant. Require human approval when an action exceeds the permissions already assigned to the agent. Before production, verify that the boundary prevents cross-user and cross-tenant retrieval, limits credential reuse and egress, separates memory, and supports revocation. Repeat after changes. ## How does Northflank support isolated agent infrastructure? Northflank supports isolated agent infrastructure with sandboxes, identity and secret controls, private networking, audit logs, and customer-cloud deployment. Your application remains responsible for record-level authorization and tool policy. - **Execution and access:** MicroVM-backed [sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank), [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [scoped API roles](https://northflank.com/docs/v1/application/secure/grant-api-access), [SAML or OIDC SSO](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation#configure-single-sign-on-sso), [directory sync](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation#sync-your-directory), [MFA enforcement](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication), and [secret injection](https://northflank.com/docs/v1/application/secure/inject-secrets) separate workloads, people, and credentials. - **Networking and evidence:** [Private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank#private-networking), BYOC [network policies](https://northflank.com/docs/v1/application/network/configure-network-policies), and [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) provide infrastructure boundaries and platform events. - **Deployment control:** Use [Northflank Cloud](https://northflank.com/cloud/northflank) for managed infrastructure or [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud) to run workloads, databases, and private networking in your cloud account. - **Agent-native operations:** [Northflank Skills](https://github.com/northflank/skills) helps coding agents operate services, databases, sandboxes, GPU workloads, previews, and releases through the API and CLI. The agent's credentials and permissions still govern access. - **Compliance:** Northflank is SOC 2 Type 2 compliant and HIPAA compliant, with BAAs supported under Enterprise contracts. [See Northflank security details](https://northflank.com/security). With BYOC, runtime, databases, storage, private networking, and the application data path can remain in your cloud boundary, while Northflank's hosted control plane retains platform metadata. Review other data flows separately. Your retrieval broker decides which records the agent may see; Northflank constrains infrastructure access. See [Northflank for Enterprise](https://northflank.com/enterprise) for the wider governance model. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your architecture, security, compliance, networking, or data-residency requirements. ## Frequently asked questions about isolating AI agents with company data ### Does every AI agent need its own sandbox? It depends on the workload. A read-only retrieval agent may not need its own runtime sandbox if identity, data authorization, tenant partitioning, and network controls provide adequate separation. An agent that executes generated code, dependencies, user files, or untrusted repositories needs a stronger runtime boundary. [Northflank sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) provide microVM-backed environments for these higher-risk workloads on Northflank Cloud or suitable BYOC node pools. ### Is a private model enough to protect company data? No, a private model alone is not enough to protect company data. Private inference can support data-location requirements, but it does not control retrieval permissions, connector access, retained memory, network egress, or downstream actions. You must secure the complete path between the agent and company data. ### Should an agent use the employee's permissions? Generally, an agent should not directly reuse an employee's permissions. Use the employee's identity to establish maximum scope, then give the agent a narrower identity and task permissions. Northflank's [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), scoped API roles, and workload identity can separate platform, API, and cloud-resource access instead of reusing an employee credential. ### When should an enterprise use BYOC for an AI agent? Use BYOC for private connectivity, infrastructure ownership, regional placement, cloud IAM integration, or defined data-residency boundaries. [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud) places the agent runtime and application data path in your cloud account, while Northflank's hosted control plane retains platform metadata. Review each associated data flow separately. ### What should you log for an AI agent with company data access? Log who or what started the run, the agent and policy version, retrieved-source references, policy decisions, tool requests and results, approvals, affected resources, and state changes. Record prompts and outputs only where policy permits. Correlate application-level agent traces with [Northflank audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) for platform and configuration events. ## Related articles about secure enterprise AI agents Use these guides to extend the isolation model across deployment, infrastructure, development, and governance. - [How to deploy agents securely in enterprises](https://northflank.com/blog/how-to-deploy-agents-securely-in-enterprises): Extend isolation across tools, releases, and incident response. - [How to manage enterprise AI infrastructure](https://northflank.com/blog/how-to-manage-enterprise-ai-infrastructure): Plan governance and ownership across AI workloads. - [Enterprise AI remote coding environments](https://northflank.com/blog/enterprise-ai-remote-coding-environments): Isolate development environments for coding agents. - [How enterprises should govern AI-built applications at scale](https://northflank.com/blog/how-enterprises-should-govern-ai-built-applications-at-scale): Apply access and lifecycle controls at scale.

How to deploy AI-built applications securely in your own cloud

2026-08-11T16:39:00.000Z

Deploying an AI-built application securely in your own cloud means treating generated code as untrusted input, then placing the verified application inside a cloud boundary your enterprise controls. That boundary controls infrastructure, networking, regional placement, IAM, and billing, but cannot repair vulnerable code or excessive permissions. The secure path starts before deployment and continues through production operations. This guide covers assessment, source and dependency security, cloud landing zones, access, networking, testing, release, and day-two operations. ## TL;DR: How to deploy AI-built applications securely in your own cloud To deploy an AI-built application securely in your own cloud, run it through your normal secure software delivery process and deploy it into a governed cloud environment with identity, data, network, release, and operational controls attached by default. - Classify the application by its data, users, actions, integrations, and availability needs before choosing infrastructure. - Move the generated code into an organization-owned repository and review code, dependencies, build files, and deployment configuration. - Define exactly which workloads and data stay in your cloud, including the location of logs, images, backups, DNS, and control-plane metadata. - Use SSO, RBAC, workload identities, injected secrets, private networking, and narrow ingress and egress. - Test the complete application in an isolated preview, then promote a traceable artifact through gated releases with rollback and audit evidence. If your enterprise needs AI-built applications to run in infrastructure your enterprise controls, [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud) keeps application workloads and workload data in your own cloud account, with deployment and operations managed through the Northflank application platform. You can deploy services, jobs, databases, and volumes with SSO, RBAC, secret injection, private networking, preview environments, release workflows, health checks, and platform audit logs under one operating model. You can also begin on [Northflank Cloud](https://northflank.com/features/managed-cloud) and use BYOC when an application requires a customer-owned VPC, regional placement, existing cloud commitments, or a specific workload-data boundary. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## Which security boundary does deploying an AI-built application in your own cloud control? Deploying in your own cloud controls where the application runs and which infrastructure policies surround it. It does not secure the code, dependencies, credentials, or user permissions. Treat security as a set of connected responsibilities: | Layer | Primary decision | What to verify | | --- | --- | --- | | Application | What the code can do | Authentication, authorization, input handling, business logic, data access | | Software supply chain | What enters the build | Source review, dependencies, build scripts, scans, artifact provenance | | Platform | How software reaches production | Identity, secrets, networking, previews, approvals, rollback, audit logs | | Cloud | Where workloads run | Account, VPC or VNet, region, IAM, encryption, cluster and node policy | | Operations | How risk is managed after launch | Monitoring, backups, patching, incident response, ownership, retirement | This layered view is especially important for AI-built applications because AI coding tools can change more than application files. They can produce package lifecycle scripts, Dockerfiles, CI workflows, infrastructure definitions, and commands that execute automatically in trusted environments, so give those files and any changes that introduce network access or shell execution additional scrutiny during review. The same secure development requirements you apply to human-written software also apply to AI-built applications. Review the application against your requirements for authentication, access control, validation, data protection, logging, and configuration. The builder may have changed, but the production risk has not disappeared. ## How should you assess an AI-built application before deployment? Assess the application by what it can reach and change, not by which AI tool generated it. For example, a static internal directory and a finance workflow that writes to a production system should not pass through the same release gate. Screen its data sensitivity, users, permitted actions, connectivity, runtime behavior, and failure impact. Higher-impact applications need stronger review, isolation, approval, and recovery requirements. Assign application and operational owners before production. Record who approves access, owns data integrations, responds to alerts, patches dependencies, rotates credentials, and retires the service. Extend that model across the [access, security, and lifecycle of every AI-built application](https://northflank.com/blog/how-enterprises-should-manage-ownership-access-and-security-for-ai-built-apps). ## What secure deployment architecture should you use for AI-built applications? A secure deployment architecture creates a traceable path from generated source to an observable workload in your cloud. The following seven stages put the broader [enterprise lifecycle of an AI-built app](https://northflank.com/blog/from-prototype-to-production-the-enterprise-lifecycle-of-an-ai-built-app) into a practical deployment sequence rather than proposing a new industry standard. ### 1. Move the code into an organization-owned repository An organization-owned repository establishes custody, history, review, and offboarding. Import lockfiles, migrations, infrastructure configuration, and build files. Remove credentials and sensitive prompt output, protect the production branch, and review package scripts, Dockerfiles, CI, deployment templates, authentication, and migrations. ### 2. Verify the code and its dependencies AI-generated tests are not independent security evidence. Run functional tests, dependency and secret scanning, useful static analysis, authorization tests, and manual review of sensitive flows. Remove unnecessary dependencies and inspect install and build scripts for remote downloads or unexpected shell commands. Create an inventory of dependencies, for example through a software bill of materials (SBOM), and preserve provenance from source commit to artifact. The objective is to know which components entered a release and which deployed applications are affected when a dependency becomes vulnerable. ### 3. Build one repeatable deployment artifact Build a versioned container image or another immutable artifact in CI. Link it to the source commit, scans, dependency inventory, and build record, and restrict who can publish to the production registry. Promote the same artifact through staging and production where practical, injecting environment-specific configuration at deployment time. With CI enabled, Northflank automatically [builds an image from each matching Git commit](https://northflank.com/docs/v1/application/build/build-code-from-a-git-repository). Images are stored in Northflank's managed registry by default, or automatically pushed to your [custom build registry](https://northflank.com/docs/v1/application/build/use-custom-build-registry) when one is configured for the project. ### 4. Create the landing zone in your cloud The landing zone defines where approved applications can run: the cloud account, VPC or VNet, region, cluster, node pools, IAM, DNS, registry, logs, backups, and cost boundary. Document where application data, secrets, logs, images, build inputs, backups, DNS data, and platform metadata live instead of relying on the label “BYOC.” If your platform can import existing Kubernetes, evaluate BYOK separately: Northflank BYOC provisions a new cluster in your cloud account, while [Northflank BYOK imports an existing Kubernetes cluster](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements) for Northflank to manage and recommends a new, dedicated cluster for the import. Separate environments, use dedicated workload identities, and apply quotas, placement, redundancy, and budgets according to risk. If you are still choosing the platform layer, compare how a [PaaS that runs in your own cloud account](https://northflank.com/blog/best-paas-that-runs-in-my-own-cloud-account-bypc-self-hosted-paas) handles both the infrastructure boundary and the day-two operational work. ### 5. Apply identity, secrets, and network policy Connect workforce access to your identity provider, grant roles by team and environment, and separate deployment permission from production-secret access. Give the workload a scoped identity and short-lived credentials where supported. Inject secrets only into services that need them, with rotation and revocation defined. Keep databases, queues, internal APIs, and administrative routes private; require SSO for employee services and restrict public ingress and egress. A VPC is a boundary, not a policy. On Northflank, you can [inject build arguments and runtime variables](https://northflank.com/docs/v1/application/secure/inject-secrets) into individual services and jobs, or use secret groups when multiple resources need the same values. You can connect internal services and databases through [private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank) and use [path-based security policies](https://northflank.com/docs/v1/application/network/create-path-based-security-policies) to place employee-facing routes behind corporate SSO. ### 6. Test the full stack before production Create an isolated preview for the exact change, including workers, representative configuration, and an isolated database or safe fixtures. [Northflank Preview Environments](https://northflank.com/product/preview-environments) can provision ephemeral, full-stack environments containing databases, microservices, and jobs for pull requests and feature branches. Do not inherit production credentials. Test authentication, role and tenant boundaries, validation, migrations, failures, outbound calls, logging, health probes, and restoration. Require checks before promotion and remove the preview when review closes. Applications that execute user-submitted or generated code at runtime need an additional execution boundary. [Northflank sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) provide isolated execution for generated or user-submitted code. ### 7. Promote through a controlled release workflow Production should receive an identified artifact through a repeatable workflow with backups and migrations where needed, readiness checks, and tested rollback. Use approvals proportional to impact and queue stateful operations to prevent races. Retain the source commit, artifact, checks, approver, configuration change, migration result, and deployment outcome. [Northflank release workflows](https://northflank.com/docs/v1/application/release/configure-workflows) can coordinate builds, deployments, backups, migrations, resource-readiness conditions, approvals, and concurrency policies across environments. ## How do you operate AI-built applications safely after launch? Operate an AI-built application as a production service, with a named owner and explicit support and retirement plans. How quickly the application was created should not lower its operational standard, especially as you [govern a growing portfolio of AI-built applications](https://northflank.com/blog/how-enterprises-should-govern-ai-built-applications-at-scale). Configure health checks and monitor latency, errors, resource saturation, user-visible failures, and cost. Define recovery objectives and test that backups can be restored within them. Patch dependencies and base images, rotate credentials, review access, and remove unused integrations. Your operations or incident-response team should have documented procedures to disable access, revoke credentials, stop the workload, block outbound connections, and preserve evidence. Keep platform audit logs distinct from application telemetry. Use platform logs to track changes to access, secrets, configuration, builds, and deployments. Use application logs for security-relevant events and business actions, subject to your privacy and retention policy. Correlate the two with deployment and request identifiers where useful, without recording credentials or unnecessary sensitive data. ## How does Northflank deploy AI-built applications in your own cloud? Northflank lets you deploy on its managed cloud or into your own cloud via [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud), which provisions a new Kubernetes cluster in your [AWS](https://northflank.com/cloud/aws), [Google Cloud](https://northflank.com/cloud/gcp), [Microsoft Azure](https://northflank.com/cloud/azure), [Civo](https://northflank.com/cloud/civo), [Oracle Cloud](https://northflank.com/cloud/oci), or [CoreWeave](https://northflank.com/cloud/coreweave) account. [Northflank BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements) imports a compatible cluster from cloud, on-premises, or bare-metal infrastructure. For advanced governance, security, or forward-deployed control-plane requirements, see [Northflank for Enterprise](https://northflank.com/enterprise). Software vendors can use [Customer VPC Deployments](https://northflank.com/product/customer-vpc-deployments) for reusable application definitions and centralized workflows across customer clouds. Across these options, Northflank provides these capabilities: - **Build and deploy:** [Connect Git and automatically build matching commits](https://northflank.com/docs/v1/application/build/build-code-from-a-git-repository), then use Northflank's managed registry or [your own cloud registry](https://northflank.com/docs/v1/application/build/use-custom-build-registry). - **Full-stack environments:** Run [services](https://northflank.com/docs/v1/application/run/run-an-image-continuously), [jobs](https://northflank.com/docs/v1/application/run/run-an-image-once-or-on-a-schedule), [databases](https://northflank.com/docs/v1/application/databases-and-persistence/deploy-a-database), and [volumes](https://northflank.com/docs/v1/application/databases-and-persistence/add-a-volume) together, with [private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank) and [full-stack previews](https://northflank.com/product/preview-environments). - **Developer workflow:** Work through the UI, [CLI](https://northflank.com/docs/v1/api/use-the-cli), [API](https://northflank.com/docs/v1/api/use-the-api), [templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code), or [GitOps](https://northflank.com/docs/v1/application/infrastructure-as-code/gitops-on-northflank). - **Agent-native operations:** [Northflank Skills](https://github.com/northflank/skills) helps coding agents deploy and operate services, databases, sandboxes, GPU workloads, previews, and releases through the API and CLI. - **Identity and security:** [SSO, MFA, granular RBAC, and scoped API access](https://northflank.com/docs/v1/application/secure/security-on-northflank) separate platform permissions, while secrets and path-based policies protect workloads. - **Production operations:** Use logs, metrics, [health checks](https://northflank.com/docs/v1/application/production-workloads/production-operations), alerts, scaling, backups, and [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs). - **Infrastructure and data boundary:** In BYOC, workload runtime and data remain in your cloud. [Northflank's security details](https://northflank.com/security) document the separate locations or options for control-plane metadata, logs, images, DNS, and backups. - **Compliance:** [Northflank is SOC 2 Type 2 compliant and HIPAA compliant](https://northflank.com/security), with BAAs supported under Enterprise contracts. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your architecture, security, compliance, data residency, networking, or migration requirements. ## Frequently asked questions about deploying AI-built applications in your own cloud ### Does running an AI-built app in our VPC make it secure? Not on its own. A VPC provides an infrastructure boundary, but the application can still contain vulnerable code, excessive permissions, exposed secrets, unsafe dependencies, or weak authentication. Add code verification, identity, secrets, network policy, release controls, monitoring, and recovery. ### Does every AI-built application need a sandbox? It depends on the application's runtime behavior. A conventional web application that runs reviewed code can use the same container isolation model as other applications with comparable risk. Use a stronger sandbox when the application executes generated code, user-submitted code, untrusted packages, files, or commands at runtime. [Northflank sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) provide isolated execution for these untrusted-code workloads. ### What stays in our cloud with BYOC? It depends on the platform and configuration. With [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud), workload runtime and data remain in your cloud, while control-plane metadata is Northflank-hosted. Logs, metrics, builds, images, DNS, and backup types have separate location options or scopes, so map each category against your residency requirements. ### Can non-engineers deploy without receiving cloud administrator access? Yes. Put a higher-level application platform between the builder and the cloud account. On [Northflank](https://northflank.com/), a builder can work through [Git](https://northflank.com/docs/v1/application/build/build-code-from-a-git-repository), the UI, [CLI](https://northflank.com/docs/v1/api/use-the-cli), or [API](https://northflank.com/docs/v1/api/use-the-api) under [scoped RBAC](https://northflank.com/docs/v1/application/secure/security-on-northflank), while the platform manages deployment to an approved [BYOC cluster](https://northflank.com/features/bring-your-own-cloud). Keep production promotion and sensitive-secret access in separate roles. ### What should we log for an AI-built application? Log application authentication, authorization failures, security-relevant data access, important business actions, errors, and deployment correlation identifiers according to your privacy policy. Separately retain platform events for access, secrets, configuration, builds, and releases. Do not log credentials or collect sensitive content without a defined purpose and retention rule. ## Related articles about deploying and governing AI-built applications - [How to deploy agents securely in enterprises](https://northflank.com/blog/how-to-deploy-agents-securely-in-enterprises) - [How enterprises should govern AI-built applications at scale](https://northflank.com/blog/how-enterprises-should-govern-ai-built-applications-at-scale) - [From prototype to production: the enterprise lifecycle of an AI-built app](https://northflank.com/blog/from-prototype-to-production-the-enterprise-lifecycle-of-an-ai-built-app) - [How enterprises should manage ownership, access, and security for AI-built apps](https://northflank.com/blog/how-enterprises-should-manage-ownership-access-and-security-for-ai-built-apps) - [Best PaaS platforms that run in your own cloud account](https://northflank.com/blog/best-paas-that-runs-in-my-own-cloud-account-bypc-self-hosted-paas)

How to build an enterprise platform for deploying AI-generated applications

2026-08-11T16:38:00.000Z

AI coding tools make application creation easier, but generating code is only the beginning. Before production, enterprise teams need to establish ownership, verify code, control data and infrastructure access, and decide how the application will be released, operated, and retired. An enterprise deployment platform brings these responsibilities into one governed path from repository to production. This guide covers minimum deployment requirements, platform architecture, risk-based controls, infrastructure choices, production operations, success metrics, and how Northflank implements the model. ## TL;DR: How to build an enterprise platform for deploying AI-generated applications An enterprise platform for deploying AI-generated applications should turn code from any approved AI tool into a traceable, tested, governed, and operable service. - Define minimum deployment requirements before choosing the platform components. - Build enforceable control points for intake, identity, builds, previews, runtime, releases, operations, and retirement. - Apply controls according to data sensitivity, exposure, business impact, integrations, and runtime behavior. - Make the governed route self-service, then measure adoption, ownership, security, reliability, and cost. If your enterprise needs a governed path for AI-generated applications, Northflank brings CI/CD, Kubernetes, databases, previews, security, and observability into one application platform. Your teams get one path from repository to production with central controls and two deployment options: use [Northflank Cloud](https://northflank.com/features/managed-cloud) for managed infrastructure, or [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud) to run application workloads and workload data in your own cloud. [Northflank Skills](https://github.com/northflank/skills) let coding agents operate through the same controls. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## What should the platform enforce for every AI-generated application? The platform should require ownership, artifact traceability, defined access and data boundaries, controlled releases, and an operational lifecycle. Treat these as the minimum requirements every application must meet, regardless of which tool generated the code. | Requirement | Platform question | Enforced outcome | | --- | --- | --- | | Ownership | Who is accountable for this application? | Named owner, business purpose, and lifecycle state | | Source and artifact | What exactly is being deployed? | Traceable source revision, build record, and artifact identity | | Data and access | Who can use it and what can it reach? | Classified data, scoped identity, and explicit access | | Runtime | What does it execute? | Approved runtime, suitable isolation, and resource limits | | Release | How can it reach production? | Risk-based tests, evidence, and promotion rules | | Operations | How is it observed, recovered, and retired? | Telemetry, rollback, backup, ownership review, and end-of-life process | These requirements should apply regardless of which AI tool generated the application. Accept applications through standard deployment inputs such as a Git repository, Dockerfile, buildpack, or container image so teams can change generation tools without redesigning the deployment process. This deployment path forms part of the broader approach to [building an internal platform for AI-built applications](https://northflank.com/blog/building-an-internal-platform-for-ai-built-applications). ## Which architecture should enterprises build for AI-generated applications? The following reference architecture organizes the platform around connected control points from application intake through ongoing operations. Enterprises can implement them with separate tools or an integrated application platform. ### 1. Add applications to the enterprise deployment platform and assign an owner Every AI-generated application should enter the enterprise deployment platform with the information teams need to govern it. Require a repository, owner, purpose, intended users, data classification, runtime profile, target environments, and expiry date where the application is experimental. The inventory must follow the application through production so enterprise teams can find and manage it. A portal can expose the inventory, but the deployment system should enforce the metadata. This central inventory is also part of how [enterprises can enable AI-built apps without creating shadow IT](https://northflank.com/blog/enable-ai-built-apps-without-shadow-it). On Northflank, platform teams can use versioned [infrastructure-as-code templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code) to give recurring application patterns the same services, jobs, databases, networking, and configuration structure. ### 2. Identity, policy, and secrets Identity controls determine who can change the platform and what each workload can access. Separate human users, CI/CD automation, coding agents, and runtime workloads rather than sharing one broad credential between them. Use corporate SSO and directory lifecycle for people, role-based access by environment, and scoped workload identities where supported. Store credentials outside prompts and repositories, inject them only where needed, and design rotation and revocation before production. Platform identity does not replace authorization inside the application. SSO can protect deployment access, while business rules still belong in the application and its identity model. Northflank's [identity and security controls](https://northflank.com/docs/v1/application/secure/security-on-northflank) include SSO, MFA, RBAC, scoped API access, and secrets. Teams can configure build arguments and runtime variables per service or job, use secret groups across resources, and apply [path-based security policies](https://northflank.com/docs/v1/application/network/create-path-based-security-policies) to selected routes. ### 3. Build and supply-chain verification The build layer turns a source revision into a traceable artifact. Build in isolation and apply tests relevant to the workload. A production path commonly includes tests, secret detection, dependency checks, static analysis, and image scanning. Match gates to risk: code generation authority should not automatically grant production authority. The same principle underpins the controls used to [prevent AI-generated code from breaking production](https://northflank.com/blog/how-to-prevent-ai-generated-code-from-breaking-production). With CI and matching branch or pull-request rules configured, Northflank can [build images automatically from Git commits](https://northflank.com/docs/v1/application/build/build-code-from-a-git-repository). Images use Northflank's managed registry by default or are pushed to a [configured custom build registry](https://northflank.com/docs/v1/application/build/use-custom-build-registry). ### 4. Preview and pre-production validation Preview environments let reviewers test the application, not only its source. Provision an isolated instance with representative dependencies and remove it when its purpose ends. Test authentication, authorization, data access, network paths, migrations, failure behavior, and rollback where applicable. Use synthetic or masked data unless the preview is approved for the relevant classification. [Northflank Preview Environments](https://northflank.com/product/preview-environments) can provision ephemeral full-stack environments containing databases, services, and jobs for pull requests and feature branches. ### 5. Runtime, networking, and data Standardize the runtime options teams need, including web services, workers, scheduled jobs, databases, and storage. Northflank provides [services](https://northflank.com/docs/v1/application/run/run-an-image-continuously), [jobs](https://northflank.com/docs/v1/application/run/run-an-image-once-or-on-a-schedule), [databases](https://northflank.com/docs/v1/application/databases-and-persistence/deploy-a-database), [volumes](https://northflank.com/docs/v1/application/databases-and-persistence/add-a-volume), and [private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank) under the same platform. Match isolation to runtime behavior. Applications that execute generated or user-submitted code need stronger isolation and tighter resource and network limits. [Northflank sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) provide microVM-backed containers with separate kernels. Agents that act on external systems need the additional controls covered in [how to deploy agents securely in enterprises](https://northflank.com/blog/how-to-deploy-agents-securely-in-enterprises). Keep services private by default and expose ingress explicitly. Set health checks, backups, recovery objectives, and data lifecycle rules according to application criticality. ### 6. Release and environment promotion Release controls should promote verified changes through development, staging, and production. Promote the same tested artifact where practical. Policy can evaluate test results, vulnerabilities, ownership, environment, data tier, and approvals before promotion. For critical services, use progressive rollout, health signals, and a tested rollback. [Northflank workflows](https://northflank.com/docs/v1/application/release/configure-workflows) can coordinate builds, deployments, backups, migrations, resource-readiness conditions, approvals, and concurrency policies across environments. ### 7. Observability, audit, and lifecycle Operations need application telemetry and platform evidence. Logs, metrics, and traces explain runtime behavior; audit events explain who or what changed a platform resource. Connect them through application, environment, release, and artifact identifiers. After launch, assign patching, access review, incident response, backup testing, cost review, and retirement. Surface orphaned applications and provide a controlled path to revoke access, retain required data, and remove infrastructure. These responsibilities fit into the wider operating model for [managing enterprise AI infrastructure](https://northflank.com/blog/how-to-manage-enterprise-ai-infrastructure). Northflank [production operations](https://northflank.com/docs/v1/application/production-workloads/production-operations) include logs, metrics, health checks, alerts, and autoscaling. [Audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) record platform changes separately from application telemetry. ## How should deployment and governance controls change by application risk? Controls should become stronger with data sensitivity, exposure, criticality, external effects, privileged integrations, and runtime code execution. Risk tiers prevent uncontrolled releases without making teams avoid the platform. | Tier | Example | Minimum path | | --- | --- | --- | | Experiment | Time-limited internal prototype using synthetic data | Named owner, preview environment, expiry, no production credentials or data | | Internal production | Employee workflow connected to company systems | SSO, scoped secrets, automated tests, audit evidence, backup, and rollback | | Sensitive or high-impact | Regulated data, public exposure, privileged actions, or runtime code execution | Threat model, security review, stronger isolation and network controls, recovery test, and explicit promotion | This table is a heuristic, not an industry standard. Define tiers with security, data, architecture, and application teams. Give exceptions an owner and expiry rather than allowing a permanent bypass. Start with one common application pattern and one target environment, then prove the full path from repository to production with real teams. Add more workload types, infrastructure targets, and controls when demand or risk requires them. ## How does Northflank implement an enterprise platform for AI-generated applications? Northflank gives enterprise teams one operating model for building, deploying, and operating AI-generated applications. It implements that model through: - **Developer workflows:** Work through the UI, [CLI](https://northflank.com/docs/v1/api/use-the-cli), [API](https://northflank.com/docs/v1/api/use-the-api), [templates](https://northflank.com/docs/v1/application/infrastructure-as-code/infrastructure-as-code), or [GitOps](https://northflank.com/docs/v1/application/infrastructure-as-code/gitops-on-northflank). - **Full-stack application infrastructure:** Run [services](https://northflank.com/docs/v1/application/run/run-containers-and-micro-services), [jobs](https://northflank.com/docs/v1/application/run/run-an-image-once-or-on-a-schedule), [databases](https://northflank.com/docs/v1/application/databases-and-persistence/deploy-a-database), [volumes](https://northflank.com/docs/v1/application/databases-and-persistence/add-a-volume), [previews](https://northflank.com/product/preview-environments), and [release workflows](https://northflank.com/docs/v1/application/release/configure-workflows) under one platform. - **Identity and security:** Apply [SSO](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication#single-sign-on), [MFA](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication#multi-factor-authentication), [granular RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), and [scoped API access](https://northflank.com/docs/v1/api/use-the-api), alongside [secrets](https://northflank.com/docs/v1/application/secure/inject-secrets) and [network policies](https://northflank.com/docs/v1/application/network/create-path-based-security-policies). - **Agent-supported operations:** Use [Northflank Skills](https://github.com/northflank/skills) to give supported coding agents context for deploying and operating workloads. - **Enterprise controls:** Use [Northflank for Enterprise](https://northflank.com/enterprise) for advanced governance, security, contractual support, or forward-deployed control-plane requirements. - **Compliance:** [Northflank is SOC 2 Type 2 compliant and HIPAA compliant](https://northflank.com/security), with BAAs supported under Enterprise contracts. Enterprises can run this operating model in the infrastructure that fits each application's security, data residency, and operational requirements. [Northflank Cloud](https://northflank.com/features/managed-cloud) runs workloads on Northflank-managed infrastructure, while [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud) provisions and manages a new Kubernetes cluster in the enterprise's [AWS](https://northflank.com/cloud/aws), [Google Cloud](https://northflank.com/cloud/gcp), [Microsoft Azure](https://northflank.com/cloud/azure), [Civo](https://northflank.com/cloud/civo), [Oracle Cloud](https://northflank.com/cloud/oci), or [CoreWeave](https://northflank.com/cloud/coreweave) account. Northflank also provides [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements) for importing a compatible Kubernetes cluster from cloud, on-premises, or bare-metal infrastructure. For software vendors, [Customer VPC Deployments](https://northflank.com/product/customer-vpc-deployments) support deploying applications into enterprise customers' infrastructure from reusable application definitions and centralized workflows. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## Frequently asked questions about enterprise platforms for AI-generated applications These answers clarify common design decisions that should remain proportional to workload risk. ### Does every AI-generated application need a sandbox? It depends on the application's runtime behavior. Conventional applications running reviewed code can use the same container isolation model as applications with comparable risk. Stronger isolation is appropriate when the application executes generated code, user-submitted code, untrusted packages, files, or commands at runtime. ### Should AI coding agents be allowed to deploy directly to production? It depends on their delegated authority, the evidence produced, and the impact of the change. Use a distinct automation identity, restrict its scope, and apply policy or human approval for high-impact actions. Do not let access to generate code silently confer broad production credentials. ### Is Kubernetes enough to build the platform? Not on its own. Kubernetes supplies orchestration, but the enterprise product still needs intake, identity, policy, secure builds, previews, release workflows, data services, observability, self-service, cost controls, and lifecycle ownership. ### Does BYOC keep all platform data inside the enterprise cloud? It depends on the provider's architecture. Verify workload execution, secrets, persistent data, networking, logs, backups, and control-plane metadata separately. A broad BYOC label is not a substitute for a data-flow and responsibility review. ### Should an enterprise build or buy this platform? Enterprises should build when the platform creates strategic differentiation or existing products cannot meet their requirements, and when they can fund long-term operation. Buying prioritizes time to a governed path and integrated operations. A managed platform deployed into the enterprise cloud offers a middle path. ## Related articles about deploying and governing AI-built applications - [How to deploy agents securely in enterprises](https://northflank.com/blog/how-to-deploy-agents-securely-in-enterprises) - [How enterprises should govern AI-built applications at scale](https://northflank.com/blog/how-enterprises-should-govern-ai-built-applications-at-scale) - [From prototype to production: the enterprise lifecycle of an AI-built app](https://northflank.com/blog/from-prototype-to-production-the-enterprise-lifecycle-of-an-ai-built-app) - [How enterprises should manage ownership, access, and security for AI-built apps](https://northflank.com/blog/how-enterprises-should-manage-ownership-access-and-security-for-ai-built-apps)

Best platforms to host AI agents in 2026

2026-08-11T16:00:00.000Z

## TL;DR: best platforms to host AI agents The best platform to host an AI agent depends on what the agent needs to do in production. - **Northflank** - Full-stack application platform for running AI agents, applications, databases, background workers, GPU workloads, and isolated sandbox environments in a single control plane. Supports microVM and gVisor-based isolation, on-demand GPUs, managed databases, CI/CD, enterprise governance, and self-serve BYOC. - **Modal** - Serverless platform for GPU-accelerated AI and machine learning workloads. - **Railway** - Application hosting platform with Git-based deployments and managed databases. - **Trigger.dev** - Background task platform with retries, scheduling, and concurrency controls. - **Amazon Bedrock AgentCore** - Managed infrastructure for deploying and operating AI agents on AWS. - **Vertex AI Agent Builder** - Managed platform for building and deploying AI agents on Google Cloud. > **If you need more than just an agent runtime:** Look for a platform where agents, databases, application services, GPUs, and secure execution environments can run through the same control plane. [Northflank](https://northflank.com/product/sandboxes) combines these capabilities with [enterprise governance](https://northflank.com/enterprise) and self-serve [BYOC](https://northflank.com/product/bring-your-own-cloud), allowing teams to run AI agents on managed infrastructure or in their own cloud and private environments. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > AI agents are moving from prototypes into production, where they need reliable infrastructure to execute tasks, access data, call tools, and maintain state. The infrastructure behind an agent becomes especially important when it can execute code, access private systems, or operate with production permissions. This guide compares platforms for hosting AI agents in production, rather than frameworks for building agent logic. It covers what to look for in an agent hosting platform, how the leading platforms compare, and which platform makes the most sense for different agent workloads. ## What is an AI agent hosting platform? An AI agent hosting platform provides the infrastructure required to run an AI agent in production. It handles the compute, networking, storage, deployment, security, and operational services that sit underneath the agent itself. This is different from an AI agent framework. Frameworks such as LangGraph, CrewAI, and AutoGen define how an agent reasons, calls tools, manages state, and coordinates tasks. A hosting platform provides somewhere for that logic to run and supplies the infrastructure the agent needs to operate reliably at scale. ## What should you look for in an AI agent hosting platform? The right platform depends on your agent's architecture and workload, but several capabilities become important as agents move from prototypes to production. - **Secure execution and isolation:** Agents that execute generated code, shell commands, user files, or untrusted dependencies need an appropriate execution boundary. Look for isolated environments with controls over networking, resources, filesystems, credentials, and workload lifetime. - **GPU access:** Agents using external model APIs may only need CPU compute, while agents running local inference or GPU-accelerated workloads need access to GPUs. - **Managed databases and persistent state:** Production agents often need databases, caches, object storage, and other services to store conversations, task state, memory, and files. - **Networking and private connectivity:** Agents may need access to internal APIs, databases, tools, and other services. Private networking and controlled ingress and egress help secure these connections. - **Deployment and scaling:** Look for Git-based deployments, automated builds, environments, deployment pipelines, autoscaling, observability, and rollback capabilities. - **Security and governance:** RBAC, SSO, secrets management, audit logging, scoped API access, and deployment permissions become important when agents have access to sensitive systems. - **Infrastructure flexibility:** If workload location, data residency, or existing infrastructure matters, look for BYOC or private deployment options. ## Best platforms to host AI agents There is no single platform that is best for every AI agent. Some focus on serverless GPU compute, others on application hosting or background jobs, while cloud providers offer managed agent infrastructure tied to their broader ecosystems. The right choice depends on your agent's execution requirements, infrastructure, security, and operational needs. ### 1. Northflank [Northflank](https://northflank.com/) is a full-stack application platform for running AI agents and the infrastructure around them. It combines secure agent sandboxes, GPU workloads, managed databases, CI/CD, preview environments, networking, and enterprise governance in a single control plane. Teams can run workloads on [Northflank Managed Cloud](https://northflank.com/features/managed-cloud) or deploy into their own infrastructure through [self-serve BYOC](https://northflank.com/product/bring-your-own-cloud). **Key features:** - [**Sandbox isolation**](https://northflank.com/product/sandboxes): Securely execute untrusted or AI-generated code in isolated environments using Kata Containers with Cloud Hypervisor, Firecracker, or gVisor, depending on the workload and infrastructure. - [**GPU workloads**](https://northflank.com/product/gpu-paas): Run AI training, inference, batch jobs, and agent workloads on H100, H200, A100, L4, L40S, and B200 GPUs alongside CPU services, sandboxes, and managed databases. - [**Managed databases**](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank): Provision PostgreSQL, MySQL, MongoDB, Redis, MinIO, and RabbitMQ with automated backups, point-in-time recovery, and database instances for preview environments. - [**CI/CD and preview environments**](https://northflank.com/product/preview-environments): Deploy from Git repositories with automated builds, deployment workflows, and isolated preview environments for testing agent applications and their dependencies. - [**Enterprise controls**](https://northflank.com/docs/v1/application/enterprise): Secure workloads with [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [SAML and OIDC SSO](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication), [secrets management](https://northflank.com/docs/v1/application/secure/security-on-northflank#secret-management), and [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) that integrate with SIEM platforms. - [**BYOC**](https://northflank.com/product/bring-your-own-cloud) **and** [**forward-deployed deployments**](https://northflank.com/enterprise): Run workloads in customer-controlled cloud, private, or on-premises infrastructure, with forward-deployed options for organizations that require the platform to run entirely within their own environment. - [**Northflank Skills**](https://github.com/northflank/skills): Deploy, manage, troubleshoot, and scale workloads directly from AI coding agents such as Claude Code, Codex, Gemini CLI, and Cursor. Northflank also supports the wider application stack around an agent, including networking, secrets, observability, deployment workflows, and supporting infrastructure. This means teams can run the agent and the services it depends on through the same platform instead of assembling separate infrastructure for each part of the workload. **Best for:** Enterprise AI agent hosting, regulated workloads, agents that execute code, and teams that need GPUs, secure sandboxes, managed infrastructure, and flexible deployment options in one platform. [Get started on Northflank](https://northflank.com/) or [book a demo with an engineer](https://cal.com/team/northflank/northflank-demo) to see if the platform fits your agent infrastructure requirements. ### 2. Modal Modal is a serverless compute platform designed around AI and machine learning workloads. Its Python-native experience and on-demand GPU infrastructure make it particularly useful for agents that need GPU compute without teams managing the underlying servers or Kubernetes infrastructure. **Key features:** - **Serverless GPU compute:** Run AI workloads on demand across a range of GPU types without managing underlying infrastructure. - **Python-native development:** Define and deploy compute workloads directly from Python. - **Autoscaling:** Scale compute resources based on workload demand. - **Sandbox environments:** Run agent-generated code and other workloads in isolated execution environments. - **Persistent volumes:** Persist model weights and other data between executions. **Best for:** AI agents that need serverless GPU compute and a Python-first development experience. ### 3. Railway Railway is a developer-focused application hosting platform for deploying services, workers, databases, and other application infrastructure. Its Git-based deployment workflow and managed databases make it a straightforward option for agent applications that primarily call external model APIs. **Key features:** - **Git-based deployments:** Deploy applications directly from connected repositories. - **Managed databases:** Provision databases such as PostgreSQL, MySQL, MongoDB, and Redis alongside applications. - **Background workers:** Run asynchronous workloads alongside agent applications. - **Environment management:** Separate development, staging, and production workloads. - **Developer-friendly workflows:** Manage applications and infrastructure through a simple application-focused interface. **Best for:** Teams building conventional AI agent applications that need simple application hosting, managed databases, and a developer-friendly deployment experience. ### 4. Trigger.dev Trigger.dev is a background task platform for building and running reliable AI agents and asynchronous workflows. It provides retries, scheduling, concurrency controls, observability, and long-running task execution without requiring teams to manage servers. **Key features:** - **Background task execution:** Run long-running and asynchronous agent workflows. - **Retries and error handling:** Automatically retry failed tasks with configurable behavior. - **Scheduling:** Run agents on schedules or recurring jobs. - **Concurrency controls:** Control how many tasks execute simultaneously. - **Task observability:** Track runs, logs, status, and execution history. **Best for:** TypeScript teams building AI agents around background jobs, scheduled tasks, and event-driven workflows. ### 5. Amazon Bedrock AgentCore Amazon Bedrock AgentCore provides managed infrastructure for deploying and operating AI agents within AWS. It includes capabilities for agent runtimes, identity, memory, tools, observability, and code execution, with deep integration into the broader AWS ecosystem. **Key features:** - **Managed agent runtime:** Deploy and run agents without managing the underlying runtime infrastructure. - **Identity:** Give agents controlled access to resources and tools through AWS-integrated identity capabilities. - **Memory:** Provide agents with managed memory for maintaining context across interactions. - **Tools and gateways:** Connect agents to tools and enterprise systems through managed interfaces. - **Observability:** Monitor agent behavior and runtime activity within the AWS ecosystem. **Best for:** AWS-native teams that want managed agent infrastructure integrated with AWS services, security, and identity. ### 6. Vertex AI Agent Builder Vertex AI Agent Builder provides managed tooling for building and deploying AI agents on Google Cloud, with integrations across Google's AI, data, and cloud services. It supports different development approaches and provides managed infrastructure for teams building agents within the Google Cloud ecosystem. **Key features:** - **Managed agent runtime:** Deploy and operate agents using Google Cloud infrastructure. - **Agent development tools:** Build agents using Google's development frameworks and supported agent technologies. - **RAG and grounding:** Connect agents to enterprise data and Google's search and AI capabilities. - **Google Cloud integration:** Connect agents to Google Cloud services, data, and infrastructure. - **Enterprise security:** Use Google Cloud IAM and related security controls to govern agent workloads. **Best for:** Teams already invested in Google Cloud that want managed agent infrastructure and native integration with Google's AI and data services. ## How to choose the best AI agent hosting platform | **Factor** | **What to consider** | **Best suited platforms** | | --- | --- | --- | | **Execution and isolation** | Does your agent execute code or untrusted workloads? Look for appropriate runtime isolation and execution controls. | **Northflank, Modal, Railway** | | **GPU requirements** | Do you need GPUs for local model inference or other accelerated workloads? | **Northflank, Modal** | | **Application infrastructure** | Do you need databases, storage, networking, deployment workflows, and other services alongside your agent? | **Northflank, Railway** | | **Enterprise requirements** | Do you need RBAC, SSO, audit logs, private networking, or deployment in your own infrastructure? | **Northflank, AWS, Google Cloud** | | **Development ecosystem** | Does the platform fit your language, framework, and existing cloud environment? | **Northflank, Modal, Trigger.dev, AWS, Google Cloud, Railway** | For most production AI agents, start with the execution environment and infrastructure the workload actually requires. If you need secure execution, GPUs, persistent services, enterprise controls, and flexible deployment in one platform, [Northflank](https://northflank.com/) is the strongest fit. Specialized platforms such as Modal and Trigger.dev can be a better choice when your requirements are primarily GPU compute or background task execution. ## FAQ: best platforms to host AI agents ### What is the difference between an AI agent framework and an AI agent hosting platform? An AI agent framework defines how an agent works, including its reasoning, tool calls, state management, and workflows, while a hosting platform provides the infrastructure where that agent runs in production. Frameworks such as LangGraph and AutoGen can run on different hosting platforms. ### Do AI agents need a sandbox? Not every agent needs a dedicated sandbox. Agents that execute generated code, shell commands, user files, or untrusted repositories should use an isolated execution environment with appropriate controls for networking, resources, filesystem access, and credentials. ### Do AI agents need GPUs? Only when the workload requires local GPU compute. Agents that use hosted models from providers such as OpenAI, Anthropic, or Google can generally run on CPU infrastructure, while agents running local models or GPU-accelerated workloads need access to GPUs. ### Which platform is best for hosting AI agents? There is no single platform that is best for every agent. Northflank is a strong option for teams that need secure execution, GPUs, managed infrastructure, enterprise governance, and flexible deployment, while Modal, Railway, Trigger.dev, AWS, and Google Cloud are better suited to specific workload or cloud ecosystem requirements. ### Can AI agents run in a customer's cloud account? Yes, depending on the platform. Northflank supports self-serve BYOC, allowing workloads to run inside customer-controlled infrastructure, while other platforms offer different forms of enterprise deployment, self-hosting, or cloud-specific infrastructure. ### Can AI agents execute code safely? AI agents can execute code more safely when the execution environment is isolated and tightly controlled. Useful controls include isolated execution, restricted network access, resource limits, ephemeral workloads, scoped credentials, and controlled filesystem access. ## Conclusion The best platform to host an AI agent depends on what the agent actually needs to do in production. A lightweight agent that calls external model APIs may only need application hosting and a database. An agent that executes untrusted code needs stronger isolation and network controls, while an agent running local models may also require dedicated GPU infrastructure. Northflank is particularly well-suited to teams that want these capabilities in one place. It combines secure agent sandboxes, GPU workloads, managed databases, application deployment, networking, observability, enterprise governance, and self-serve BYOC in a single platform. [Get started on Northflank](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to explore infrastructure for production AI agents. ## Related articles - [**Top AI agent runtime tools**](https://northflank.com/blog/top-ai-agent-runtime-tools) - [**What are computers for AI agents?**](https://northflank.com/blog/what-are-computers-for-ai-agents) - [**Best enterprise AI sandbox platforms**](https://northflank.com/blog/best-enterprise-ai-sandbox-platforms) - [**How to secure AI agents in the cloud**](https://northflank.com/blog/how-to-secure-ai-agents-in-the-cloud)

How to deploy agents securely in enterprises in 2026

2026-08-10T16:31:00.000Z

Deploying AI agents securely in an enterprise means controlling what each agent can access, execute, change, and retain. The security boundary extends beyond the model to the agent's identity, tools, execution environment, data, network paths, and route to production. This guide explains how to classify agent risk and apply those controls before moving an agent from pilot to production. ## TL;DR: How to deploy agents securely in enterprises To deploy agents securely, limit their permissions, isolate risky execution, control access to data and tools, gate high-impact actions, and record what they do. - Classify each agent by its actions and potential impact before selecting controls. - Give agents task-specific identities and short-lived, scoped credentials. - Mediate tool calls and isolate generated or untrusted code. - Separate data, networks, and environments, with approval gates for high-impact actions. - Correlate agent traces with platform audit logs and use customer-controlled infrastructure when required. Enterprise agents need somewhere secure to execute code and a controlled path into the services, databases, GPUs, and deployment workflows they use. [Northflank](https://northflank.com/) runs agent sandboxes and the wider application stack on one platform, with hardware-virtualized microVM or gVisor user-space-kernel isolation, secrets management, private networking, SSO, RBAC, audit logs, preview environments, and release workflows. You can deploy on [Northflank Cloud](https://northflank.com/cloud/northflank) or use self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud) to run agent workloads and keep workload data inside your cloud account or VPC. [Northflank Skills](https://github.com/northflank/skills) also lets agents in Claude Code, Codex, Cursor, OpenCode, and Windsurf deploy and operate services, databases, sandboxes, GPU workloads, previews, and release workflows through the Northflank API and CLI. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## Why is secure agent deployment an enterprise priority in 2026? Secure agent deployment is an enterprise priority in 2026 because agents are moving into production workflows where they can access sensitive data, execute code, call tools, and change business systems. Unlike assistants that primarily generate responses, agents can plan and execute multi-step work. A prompt injection can become a tool call, while poisoned memory or an over-permissioned connector can affect later tasks and widen the impact across your systems. That wider impact is reflected in current security guidance. Developed with input from more than 100 experts, [OWASP's Top 10 for Agentic Applications 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) identifies critical risks across agent goals, tools, identity, memory, and multi-agent systems. [NIST's May 2026 analysis](https://www.nist.gov/publications/summary-analysis-responses-request-information-regarding-security-considerations-ai) similarly found broad agreement that existing cybersecurity practices remain relevant but must be adapted for agent-specific threats. For your enterprise, this means extending familiar security controls to cover the agent's decisions, delegated access, tool calls, memory, and runtime environment. Your main question should be: what can this agent reach and change if it is manipulated or simply wrong? If you are managing several types of AI workload, read [how to manage enterprise AI infrastructure](https://northflank.com/blog/how-to-manage-enterprise-ai-infrastructure) and compare the [top cloud platforms for enterprise AI deployment](https://northflank.com/blog/top-cloud-platforms-for-enterprise-ai-deployment). ## How should enterprises classify agents before deployment? For deployment controls, classify an agent primarily by its maximum permitted actions and resulting impact, not its model or benchmark score. The same model can support a read-only knowledge assistant or a production operations agent with a very different risk profile. A practical deployment taxonomy is: | Tier | Permitted actions | Example | Minimum controls | | --- | --- | --- | --- | | Read and recommend | Retrieve approved data and generate responses | Internal policy assistant | Scoped retrieval, filtering, and trace logging | | Prepare changes | Draft code, tickets, messages, or configuration | Coding or support agent | Isolated workspace, approved tools, and review queue | | Execute bounded actions | Perform defined, reversible actions | Restart a development service | Scoped identity, allowlisted tools, limits, and audit evidence | | Execute high-impact actions | Change production, identities, money, or critical data | Production operations agent | Explicit approval, separation of duties, rollback, and incident controls | Increase autonomy only when the control environment and operational evidence justify it. Test indirect prompt injection, malicious tool responses, permission escalation, memory poisoning, data exfiltration, malformed arguments, approval bypass, and sandbox escape attempts before granting broader authority. For coding use cases, compare the [top enterprise coding agents](https://northflank.com/blog/top-enterprise-coding-agents) and review the infrastructure needed for [enterprise AI coding agent deployment](https://northflank.com/blog/enterprise-ai-coding-agent-deployment). ## What should a secure enterprise agent architecture include? A secure architecture gives the agent enough access to complete one defined job while preventing that access from spreading across tools, environments, and future sessions. ### 1. Agent identity and credentials Give every agent or workload a named identity that you can trace, rotate, and revoke. Do not let it inherit a developer session or use a shared administrator token. Scope access by task, tool, resource, tenant, and environment. Prefer short-lived credentials and audience-bound tokens where supported. A credential issued for one service should not become a reusable key for another. Your ownership model should also identify who approves access and who removes it. The guide to [managing ownership, access, and security for AI-built apps](https://northflank.com/blog/how-enterprises-should-manage-ownership-access-and-security-for-ai-built-apps) applies the same principle to the wider application lifecycle. ### 2. Tool and MCP server controls Maintain an approved tool registry and put a deterministic policy check between the model's request and the action. Validate the tool, operation, target, parameters, environment, and data classification. Separate read and write permissions. For actions that exceed the agent's delegated authority, typically require explicit approval or another independently enforced authorization control. Examples include production deployments, destructive operations, privileged identity changes, material financial transactions, and sensitive external communications. For MCP, minimize scopes, validate token audiences, prevent token passthrough, and review server provenance and update paths. Give operators an independent containment path to terminate runs, revoke credentials, disable tools or policies, quarantine state, and block further actions. ### 3. Isolated execution for agent workloads Use an isolated sandbox when an agent runs generated code, shell commands, dependencies, user files, or untrusted repositories. Running this work inside the orchestrator or on a shared worker gives unsafe code a larger blast radius. For untrusted execution, a separate-kernel boundary such as a microVM reduces reliance on the shared host kernel. Combine it with ephemeral environments, resource limits, controlled mounts, restricted egress, and a maximum lifetime. Attach persistence only when the task needs it. This is also why the platform behind [enterprise AI remote coding environments](https://northflank.com/blog/enterprise-ai-remote-coding-environments) is as important as the coding agent itself. ### 4. Agent data and memory protection Apply your existing data classifications before information reaches the agent. Filter retrieval by user, tenant, project, geography, and purpose, and preserve provenance so you can distinguish authoritative records from untrusted content. Give agent memory an owner, retention period, access policy, and deletion path. Keep temporary working memory separate from systems of record, and validate content before making it durable. These controls are especially important when you [govern AI-built applications at scale](https://northflank.com/blog/how-enterprises-should-govern-ai-built-applications-at-scale). ### 5. Private networking and restricted access Start with deny-by-default ingress and egress, then allow only the destinations the task requires. Use private paths for internal APIs and databases, and restrict external access by destination, port, and protocol where practical. Route email, publishing, webhooks, and other outward actions through a broker that can validate the destination and apply approval policy. Network controls cannot stop prompt injection, but they can stop an injected request from reaching an unapproved system. ### 6. Controlled releases for agent-generated changes Let agents create branches and pull requests, but keep production authority in your release workflow. Build the proposed change, run tests and security checks, and create an isolated preview environment for the exact artifact you may promote. Where practical, promote the same immutable artifact through development, staging, and production with approvals and rollback. The [enterprise lifecycle of an AI-built app](https://northflank.com/blog/from-prototype-to-production-the-enterprise-lifecycle-of-an-ai-built-app) explains this progression, while [enterprise vibe coding security](https://northflank.com/blog/enterprise-vibe-coding-how-to-deploy-ai-generated-apps-safely) covers the controls needed for AI-generated code. ### 7. Agent tracing and platform audit logs Log enough information to reconstruct the complete action. Your application trace should connect the initiating identity, agent and policy version, tool request, approval, affected resource, result, latency, and cost. Correlate that trace with platform events for access controls, secrets, configuration, builds, deployments, and infrastructure changes. Use a shared run or trace ID, and redact credentials and sensitive content according to your retention policy. ## How does Northflank support secure enterprise agent deployment? Northflank gives you one deployment and governance model for agent sandboxes and the application stack around them. [See Northflank for Enterprise](https://northflank.com/enterprise) for infrastructure, governance, security, support, and deployment options. - **Isolated execution:** [Northflank sandboxes](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank) use hardware-virtualized microVM isolation or gVisor user-space-kernel isolation for untrusted and agent-generated code on Northflank Cloud or BYOC, depending on the workload and infrastructure. - **Identity and access:** [SAML or OIDC SSO](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation#configure-single-sign-on-sso), [directory sync](https://northflank.com/docs/v1/application/collaborate/manage-an-organisation#sync-your-directory), [MFA enforcement](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication), [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), and scoped [API roles](https://northflank.com/docs/v1/application/secure/grant-api-access) help you separate access by organization, team, project, and workload. - **Secrets and networking:** [Inject secrets](https://northflank.com/docs/v1/application/secure/inject-secrets) into selected workloads and use [private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank#private-networking) or [path-based security policies](https://northflank.com/docs/v1/application/network/create-path-based-security-policies) instead of exposing credentials in code or prompts. - **Controlled releases:** [Preview environments](https://northflank.com/product/preview-environments) and [release workflows](https://northflank.com/features/release-layer) give agent-generated changes a governed path through testing, approval, promotion, and rollback. - **Audit evidence:** Northflank [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs) record platform events with the triggering identity, source, timestamp, affected resource, and, for applicable events, changes to the affected configuration. You can correlate them with application-level agent traces. - **Infrastructure control:** Use [managed infrastructure](https://northflank.com/features/managed-cloud) or [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud) for customer-controlled networking, IAM, regional placement, workload data boundaries, and cloud billing. In BYOC, control-plane metadata remains Northflank-hosted. - **Compliance:** Northflank is SOC 2 Type 2 compliant and HIPAA compliant, with BAAs supported under Enterprise contracts. [See the security details](https://northflank.com/security). - **Agent-native operations:** [Northflank Skills](https://github.com/northflank/skills) lets supported coding agents deploy and operate services, databases, sandboxes, GPU workloads, previews, and release workflows through the API and CLI. [Get started with Northflank](https://app.northflank.com/signup) self-serve, or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss your architecture, security, compliance, networking, or migration requirements. ## Frequently asked questions about deploying agents securely in enterprises These answers address the security and infrastructure questions you are likely to encounter before production approval. ### Is a private model enough to secure an enterprise agent? Not on its own. Private hosting can support your data-boundary requirements, but it does not replace identity, tool, execution, network, release, and audit controls. [Northflank BYOC](https://northflank.com/product/bring-your-own-cloud) can run your model, agent, and surrounding services inside your cloud account or VPC when infrastructure ownership is part of the requirement. ### Does every enterprise agent need a sandbox? It depends on what the agent can do. A read-only retrieval agent may be adequately separated through identity, application, data, and network controls. If your agent runs generated code, dependencies, user files, or untrusted repositories, use a stronger execution boundary. [Northflank sandboxes](https://northflank.com/product/sandboxes) can use hardware-virtualized microVM isolation or gVisor user-space-kernel isolation, depending on the workload and infrastructure. ### How should enterprises secure MCP servers and tools? Approve each server, verify its provenance, minimize scopes, use audience-bound tokens, validate redirects, prohibit token passthrough, and apply policy before consequential actions. You can run MCP servers on Northflank with the same secrets, private networking, RBAC, and deployment controls as your other services, while keeping application-level tool authorization explicit. ### When should an enterprise use BYOC for agents? Use BYOC when you need private connectivity, infrastructure ownership, regional placement, existing IAM, cloud commitments, or specific workload data boundaries. [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud) runs agent workloads and keeps workload data inside your cloud environment. Control-plane metadata remains Northflank-hosted. ### What should enterprises log for an AI agent? Log the initiating identity, agent and policy version, policy decision, tool request and result, approval, affected resource, state change, and correlation ID. Record relevant inputs and outputs only where your policy permits. Northflank audit logs provide the platform side of this record; do not place credentials or unnecessary sensitive data in either layer. ## Related articles about secure enterprise AI deployment Use these guides to extend your agent security controls across builders, applications, governance, and platform selection. - [What is the best IDP for highly regulated industries?](https://northflank.com/blog/what-is-the-best-idp-for-highly-regulated-industries): Compare platform controls for regulated development and deployment. - [How enterprises can enable AI-built apps without creating shadow IT](https://northflank.com/blog/enable-ai-built-apps-without-shadow-it): Give teams an approved path for building and deploying AI applications. - [What CTOs should know about deploying AI-built apps](https://northflank.com/blog/what-ctos-should-know-about-deploying-ai-built-apps): Review the architecture and operating decisions behind AI application delivery. - [Best enterprise-safe platforms for running and hosting AI apps](https://northflank.com/blog/best-enterprise-safe-platforms-for-running-and-hosting-ai-apps): Compare platforms by security, governance, and infrastructure control. - [How marketing teams can build AI apps securely](https://northflank.com/blog/how-marketing-teams-can-build-ai-apps-securely): Apply enterprise controls to AI applications built outside engineering. - [How non-technical employees can build and ship internal apps with AI securely](https://northflank.com/blog/how-non-technical-employees-can-build-and-ship-internal-apps-with-ai-securely): Create a governed route from internal idea to production.

Vercel-like developer experience for Kubernetes deployments

2026-08-10T15:15:00.000Z

## TL;DR: Vercel-like DX for Kubernetes deployments A Vercel-like experience on Kubernetes should give developers the simplicity of modern application platforms while Kubernetes remains the underlying infrastructure. Look for: - Git-based deployments and automatic builds - Preview environments for every pull request - Deployment pipelines, rollbacks, and managed networking - Managed databases, secrets, and observability - Developer self-service and AI-native workflows > [Northflank](https://northflank.com/) brings a Vercel-like developer experience to Kubernetes, [combining Git-based deployments](https://northflank.com/product/deployments), [preview environments](https://northflank.com/product/preview-environments), deployment pipelines, [managed databases](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), [secrets management](https://northflank.com/docs/v1/application/secure/manage-secret-groups), [observability](https://northflank.com/docs/v1/application/observe/observability-on-northflank), [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [SSO](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication) , [GPU workloads](https://northflank.com/product/gpu-paas), [sandboxes](https://northflank.com/product/sandboxes), and [Northflank Skills](https://github.com/northflank/skills) for AI agents in a single platform. Deploy on [Northflank Managed Cloud](https://northflank.com/features/managed-cloud) or into your own Kubernetes infrastructure with [self-serve BYOC](https://northflank.com/features/bring-your-own-cloud). [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > Kubernetes gives teams a powerful way to run and scale applications, but it does not define how developers should build, deploy, and operate those applications. Developers still have to interact with manifests, namespaces, ingress, services, secrets, CI/CD systems, and other Kubernetes components unless a platform abstracts that complexity. Vercel popularized a different model: connect a repository, push code, get a deployment, create a preview for every pull request, and roll back when something goes wrong. A Vercel-like Kubernetes experience brings that same simplicity to Kubernetes while allowing platform teams to retain the flexibility, control, and portability of Kubernetes. ## What is a Vercel-like DX for Kubernetes **deployments**? A Vercel-like developer experience for Kubernetes means giving developers a simple, self-service way to build, deploy, preview, and operate applications while Kubernetes remains the underlying infrastructure. Developers should be able to connect a Git repository, push code, create environments, view deployments, and roll back changes without having to work directly with Kubernetes manifests or cluster configuration. The underlying Kubernetes infrastructure still matters for platform teams. They retain control over clusters, networking, security, resources, and governance, while developers interact with a higher-level application platform. The goal is to make Kubernetes feel invisible for routine application delivery without removing the flexibility Kubernetes provides underneath. ## Why Kubernetes doesn't provide a Vercel-like developer experience by itself Kubernetes is designed to orchestrate containers, not to provide an opinionated application deployment experience. It gives teams the primitives needed to run applications at scale, but developers still need additional tooling to turn those primitives into a streamlined workflow. A typical Kubernetes environment might involve GitHub Actions or GitLab CI for builds, Argo CD or Flux for deployment, an ingress controller for networking, cert-manager for TLS, a secrets manager for credentials, Prometheus and Grafana for observability, and separate systems for databases and other infrastructure services. Each component can solve an important problem, but developers are left interacting with a collection of systems rather than one cohesive application platform. This is where the difference between **running applications on Kubernetes** and **providing a developer platform on Kubernetes** becomes important. A Vercel-like experience abstracts these operational details so developers can focus on their applications while platform teams retain control over the underlying Kubernetes infrastructure. ## What should you look for in a platform that offers Vercel-like DX for Kubernetes? A platform that brings Vercel-like developer experience to Kubernetes should do more than automate deployments. It should remove the operational complexity developers encounter throughout the application lifecycle. When evaluating a platform, look for the following capabilities: - **Git-based deployments:** Developers should be able to connect a Git repository and automatically build and deploy applications from commits without manually managing Kubernetes manifests or deployment configuration. - **Preview environments:** Every pull request should be able to create an isolated environment with the application and its dependencies, giving developers and reviewers a live environment to validate changes before they reach production. - **Deployment pipelines and rollbacks:** The platform should support automated promotion between environments, deployment approvals, deployment history, and straightforward rollbacks when a release fails. - **Managed networking:** Applications should receive public or private endpoints, custom domains, DNS, and TLS without developers having to configure ingress resources, load balancers, or certificates manually. - **Secrets and configuration management:** Secrets should be managed centrally and securely injected into workloads without requiring developers to commit credentials or manually create Kubernetes Secret objects. - **Managed infrastructure services:** Developers should be able to provision databases, caches, object storage, queues, jobs, and other application dependencies alongside their workloads. - **Observability:** Logs, metrics, deployment history, and application health should be available through the same platform developers use to deploy their applications. - **Developer self-service:** Developers should be able to create environments, deploy services, provision infrastructure, and troubleshoot applications without opening tickets for routine Kubernetes operations. - **Enterprise governance:** Platform teams should retain RBAC, SSO, audit logging, secrets controls, and deployment permissions while allowing developers to work independently. - **AI-native workflows:** AI coding assistants should be able to interact with the same application platform, allowing them to deploy applications, provision services, create preview environments, and troubleshoot workloads through governed workflows. The goal is not to hide Kubernetes from platform engineers. It is to **hide unnecessary Kubernetes complexity from application developers** while preserving the capabilities that make Kubernetes useful in the first place. ## Comparing Kubernetes platforms that offer Vercel-like DX for deployments Kubernetes platforms differ in how much of the application deployment experience they provide out of the box. The following comparison focuses on the capabilities that matter when looking for a Vercel-like experience on Kubernetes. **Note:** Native means built in and ready to use. Included means provided through the product or another first-party component, but may require additional setup or licensing. Add-on means it requires third-party tools or additional configuration. Partial means it covers only part of the workflow. | Capability | Northflank | OpenShift | Platform9 | Rancher | VMware Tanzu | | --- | --- | --- | --- | --- | --- | | Git-based deployments | Native | Included | Add-on | Native (manifests only) | Included (cf push) | | Automatic builds from source | Native | Included (S2I, Builds) | Add-on | Add-on | Included (buildpacks) | | Preview environment per pull request | Native | Add-on | Add-on | Add-on | Add-on | | Deployment pipelines and rollbacks | Native | Included (Tekton) | Add-on | Partial (delivery only) | Included (Concourse) | | Managed networking and TLS | Native | Native (Routes) | Partial (MetalLB only) | Included (ingress) | Native (gorouter) | | Secrets and configuration | Native | Kubernetes secrets | Kubernetes secrets | Kubernetes secrets | Native (CredHub) | | Managed databases and services | Native | Add-on | Add-on | Add-on | Included (Tanzu Data) | | Observability | Native | Native | Infrastructure only | Included (charts) | Partial | | AI coding assistant workflows | Native ([Northflank Skills](https://github.com/northflank/skills)) | Yes | No | Partial | No | | Signup to production without a platform team | Yes | No | No | No | No | ## Why teams choose Northflank for Kubernetes deployments Kubernetes gives platform teams the infrastructure and orchestration capabilities they need, but developers should not have to interact with Kubernetes directly for everyday application delivery. Northflank adds an application platform on top of Kubernetes, giving developers a Vercel-like experience while platform teams retain control over the underlying clusters and infrastructure. With Northflank, teams can run applications on **Northflank Managed Cloud** or deploy the platform into their own infrastructure through **self-serve BYOC**. This means organizations can keep Kubernetes as their underlying infrastructure while giving developers and AI coding assistants a consistent, self-service way to build, deploy, and operate applications. Organizations choose Northflank because it provides: - [**Git-based deployments**](https://northflank.com/product/deployments): Connect GitHub, GitLab, or Bitbucket repositories and automatically build and deploy applications from commits. Developers don't need to write Kubernetes manifests or configure deployment tooling for every service. - [**Preview environments**](https://northflank.com/product/preview-environments): Automatically create isolated environments for every pull request, including application services and their dependencies. Developers and reviewers get a live URL to test changes before merging. - [**Deployment pipelines and rollbacks**](https://northflank.com/docs/v1/application/release/ci-cd-on-northflank): Build promotion workflows across development, staging, and production, with deployment approvals, deployment history, and straightforward rollbacks when something goes wrong. - [**Managed databases and infrastructure**](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank): Provision PostgreSQL, MySQL, MongoDB, Redis, RabbitMQ, MinIO, object storage, jobs, and cron jobs alongside applications without maintaining separate infrastructure workflows. - [**Managed networking and TLS**](https://northflank.com/docs/v1/application/network/networking-on-northflank): Give applications accessible endpoints, custom domains, and TLS without requiring developers to configure Kubernetes ingress resources, certificates, or load balancers manually. - [**Secrets and configuration management**](https://northflank.com/docs/v1/application/secure/manage-secret-groups): Centralize application secrets and configuration and securely inject them into workloads at build and runtime. - [**Observability**](https://northflank.com/docs/v1/application/observe/observability-on-northflank): Give developers access to logs, metrics, deployment history, and application health from the same platform they use to deploy their applications. - **Enterprise security and governance**: Provide [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [SAML and OIDC SSO](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication), [audit logging](https://northflank.com/docs/v1/application/observe/audit-logs), deployment permissions, and centralized controls while allowing developers to self-serve routine application operations. - [**GPU workloads**](https://northflank.com/product/gpu-paas) **and** [**secure sandboxes**](https://northflank.com/product/gpu-paas): Run GPU workloads alongside standard applications and use Firecracker microVMs, Kata Containers with Cloud Hypervisor, or gVisor when applications need stronger workload isolation. - **AI-native platform operations:** **With** [**Northflank Skills**](https://github.com/northflank/skills), AI coding assistants such as Claude Code, Codex, Cursor, and Gemini CLI can deploy applications, provision databases, create preview environments, configure infrastructure, and troubleshoot workloads through the same governed platform. The result is a separation of concerns: developers work with applications, environments, and deployments, while platform teams manage the underlying Kubernetes infrastructure, security, and governance. Northflank provides the higher-level experience without requiring teams to replace Kubernetes or assemble a separate collection of tools around it. ## FAQ: Vercel-like DX for Kubernetes ### What is a Vercel-like developer experience for Kubernetes? A Vercel-like developer experience means giving developers a simple, self-service way to build, deploy, preview, and operate applications without requiring them to manage Kubernetes directly. This typically includes Git-based deployments, preview environments, deployment pipelines, managed networking, secrets, observability, and easy rollbacks. ### Can Kubernetes provide a Vercel-like developer experience? Kubernetes provides the underlying orchestration layer, but it does not provide the complete developer experience by itself. Teams typically need additional tooling or an application platform to provide automated builds, preview environments, CI/CD, managed services, networking, secrets management, and developer self-service. ### Do developers need Kubernetes expertise to deploy applications? They shouldn't have to. A platform built on Kubernetes can abstract Kubernetes primitives behind higher-level workflows, allowing developers to deploy applications from Git, create environments, view logs, manage configuration, and roll back deployments without writing Kubernetes manifests. ### How do preview environments work with Kubernetes? A platform can automatically create an isolated environment for each pull request, deploy the relevant application services and dependencies, and provide a temporary URL for testing. The environment can then be removed automatically when the pull request is merged or closed. ### What is the difference between Kubernetes and an application platform? Kubernetes is an orchestration system for running containerized workloads. An application platform builds on top of Kubernetes and adds the workflows developers need to build and operate applications, such as Git deployments, CI/CD, preview environments, managed databases, secrets, networking, observability, and self-service. ### Can AI coding assistants deploy applications to Kubernetes? Yes, when they are connected to an appropriate platform. With Northflank Skills, AI coding assistants such as Claude Code, Codex, Cursor, and Gemini CLI can deploy applications, provision infrastructure, create preview environments, manage databases, and troubleshoot workloads through governed platform workflows. ### Can Northflank deploy to existing Kubernetes clusters? Yes. Northflank can deploy into existing Kubernetes infrastructure through self-serve BYOC. This lets organizations keep their existing Kubernetes infrastructure while giving developers access to Northflank's higher-level application deployment experience. ## Conclusion Kubernetes provides a powerful foundation for running applications, but developers increasingly expect more than an orchestration layer. A Vercel-like experience means turning that infrastructure into a simple application workflow where developers can deploy from Git, create preview environments, promote releases, manage dependencies, and roll back changes without becoming Kubernetes experts. [Northflank](https://northflank.com/) brings this experience to Kubernetes by combining application delivery, preview environments, deployment pipelines, managed infrastructure, networking, secrets, observability, governance, and AI-native workflows in one platform. Teams can use Northflank Managed Cloud or deploy into their own Kubernetes infrastructure through self-serve BYOC, giving developers and AI coding assistants the same streamlined experience while platform teams retain control of Kubernetes. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to bring a Vercel-like developer experience to your Kubernetes deployments.

Vercel-like developer experience for on-premises deployments

2026-08-10T15:15:00.000Z

## TL;DR: Vercel-like DX for on-prem deployments A Vercel-like developer experience on your own infrastructure should provide: - Git-based deployments and preview environments - Built-in networking, TLS, secrets, and managed services - Deployment pipelines, rollbacks, and developer self-service - Enterprise security and AI-native workflows > [Northflank](https://northflank.com/) brings this developer experience to [**Northflank Managed Cloud**](https://northflank.com/features/managed-cloud), [**self-serve BYOC**](https://northflank.com/product/bring-your-own-cloud), and [**forward-deployed deployments**](https://northflank.com/enterprise), combining [Git deployments](https://northflank.com/product/deployments), [preview environments](https://northflank.com/product/preview-environments), deployment pipelines, [managed databases](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), [secrets management](https://northflank.com/docs/v1/application/secure/manage-secret-groups), [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [SSO](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication), [audit logging](https://northflank.com/docs/v1/application/observe/audit-logs), [AI-native workflows](https://github.com/northflank/skills), and more from a single platform. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > Vercel transformed how developers expect software deployment to work. Connect a repository, push code, and get a production deployment or preview environment without worrying about the underlying infrastructure. Many organizations want that same experience while keeping applications on infrastructure they control. Compliance requirements, data residency, existing cloud investments, private infrastructure, and air-gapped environments can all make a managed public platform unsuitable. This guide explains what a Vercel-like developer experience means for on-premises deployments, what capabilities to look for, the different approaches organizations can take, and how Northflank brings that experience to infrastructure you control. ## What is a Vercel-like DX for on-prem deployments? A Vercel-like developer experience for on-premises deployment means giving developers the simplicity of modern cloud platforms while running applications on infrastructure the organization controls. Developers can connect a Git repository, push code, create preview environments, deploy applications, and roll back changes without having to manage servers, networking, or infrastructure manually. The key is separating the **developer experience from the underlying infrastructure**. Developers get self-service workflows for deploying and operating applications, while platform teams retain control over their cloud accounts, private infrastructure, security, and compliance requirements. ## Why delivering a Vercel-like experience on your own infrastructure is difficult The challenge isn't simply running applications on your own infrastructure. It's recreating the developer experience that modern cloud platforms provide on top of that infrastructure. Git-based deployments, preview environments, networking, TLS, secrets, databases, rollbacks, and self-service workflows all need to work together without developers having to manage the underlying systems. Organizations can build this experience themselves by combining Kubernetes or other infrastructure with CI/CD, GitOps, networking, secrets management, observability, and developer portals. But integrating and maintaining all these components takes significant platform engineering effort. The result is often a powerful infrastructure stack that still requires developers to understand the systems underneath it, which is exactly what a Vercel-like experience is supposed to hide. ## What should you look for in a platform that offers Vercel-like DX for on-prem deployments? A Vercel-like developer experience is about much more than deploying applications. The best platforms remove operational complexity while giving developers everything they need to build, test, deploy, and operate software independently. When evaluating a platform, look for the following capabilities. - **Git-based deployments:** Developers should be able to connect a Git repository and automatically build and deploy every commit without manually configuring infrastructure or deployment pipelines - **Preview environments:** Every pull request should create an isolated preview environment with its own services, databases, and URL, making it easy to review changes before they reach production. - **Deployment pipelines and rollbacks:** The platform should support automated promotion between environments, deployment approvals, and one-click rollbacks to reduce deployment risk. - **Managed networking:** Public endpoints, custom domains, DNS, and TLS certificates should be provisioned automatically so developers don't need to configure ingress controllers or networking policies for every application. - **Secrets and configuration management:** Sensitive configuration should be centrally managed and injected securely into applications without exposing credentials in repositories or deployment manifests. - **Managed infrastructure services:** Databases, object storage, message queues, scheduled jobs, and other application dependencies should be provisioned alongside applications from the same platform instead of requiring separate management tools. - **Developer self-service:** Developers should be able to deploy applications, provision infrastructure, and manage environments without depending on the platform team for routine tasks. - **Enterprise governance:** Look for built-in RBAC, SSO, audit logging, policy controls, and compliance features that allow platform teams to maintain visibility without slowing developers down. - **Flexible deployment models:** The platform should provide the same developer experience whether applications run on managed infrastructure, inside your own cloud account through BYOC, or entirely on-premises. [Northflank](https://northflank.com/) supports all three through Managed Cloud, self-serve BYOC, and forward-deployed deployments. - **AI-native workflows:** As AI coding assistants become part of the development process, the platform should allow tools such as Claude Code, Codex, Cursor, and Gemini CLI to deploy applications, provision infrastructure, create preview environments, and manage services through governed workflows rather than unrestricted infrastructure access. These capabilities are what turn infrastructure into an **application platform**. The underlying infrastructure might be Kubernetes, virtual machines, bare metal, or another environment. Developers shouldn't need to know which one is underneath to use the platform. ## Comparing approaches to Vercel-like DX for on-prem deployments There are several ways organizations can try to provide a modern application deployment experience on infrastructure they control. They solve different parts of the problem. ### DIY Kubernetes and GitOps Organizations can combine Kubernetes with tools such as Argo CD, Flux, cert-manager, Vault, ingress controllers, Prometheus, Grafana, and other infrastructure components. This provides significant flexibility, but the organization is responsible for integrating and maintaining the developer experience. Preview environments, self-service workflows, managed databases, networking, and application lifecycle management often require additional engineering. Northflank addresses this by bringing these application lifecycle capabilities into a single platform, rather than requiring platform teams to assemble and maintain them separately. ### Enterprise Kubernetes platforms Platforms such as OpenShift, Rancher, Spectro Cloud, and VMware Tanzu provide enterprise Kubernetes management, security, governance, and infrastructure capabilities. They are useful when the primary requirement is operating Kubernetes across enterprise environments. However, Kubernetes management and a Vercel-like application deployment experience are different problems. Teams may still need additional tooling for Git-based application delivery, preview environments, managed application services, and developer self-service. Northflank can sit above existing Kubernetes infrastructure through BYOC, providing the application platform and developer experience without requiring organizations to replace their underlying infrastructure. ### Internal developer platforms Organizations can build an internal developer platform using tools such as Backstage and their existing infrastructure stack. This can create a customized developer portal, but the portal itself does not automatically provide the underlying deployment, networking, secrets, database, or preview environment capabilities. Platform teams still have to build and maintain those integrations. Northflank provides these capabilities as part of the platform, reducing the amount of internal platform engineering required to create a self-service developer experience. ### Application platforms with BYOC and on-premises deployment A different approach is to use an application platform that abstracts the infrastructure from developers while allowing workloads to run inside infrastructure controlled by the organization. This is closer to the Vercel model: developers interact with a high-level deployment platform while the organization retains control over the underlying environment. Northflank combines this model with multiple deployment options: Managed Cloud for teams that want managed infrastructure, self-serve BYOC for teams that want workloads in their own cloud accounts, and forward-deployed deployments for organizations that need the platform to run entirely within their own environment. ## Why teams choose Northflank for on-premises deployments Running applications on your own infrastructure shouldn't mean rebuilding the developer experience from scratch. Northflank gives teams a Vercel-like application platform while letting them decide where that platform and their workloads run. Northflank supports **Northflank Managed Cloud, self-serve BYOC, and forward-deployed deployments**, so organizations can choose between managed infrastructure, their own cloud accounts, or an environment entirely under their control. Developers and AI coding assistants use the same workflows across all three models, while platform teams retain control over infrastructure, security, and governance. Organizations choose Northflank because it provides: - **Deploy anywhere:** Choose the deployment model that fits your organization. Run on [Northflank Managed Cloud](https://northflank.com/features/managed-cloud), deploy into your existing AWS, Azure, GCP, OCI, CoreWeave, or on-premises infrastructure with [self-serve BYOC](https://northflank.com/features/bring-your-own-cloud), or run the entire platform inside your own environment with a [forward-deployed](https://northflank.com/enterprise) control plane. - [**Git-based deployments and deployment pipelines**](https://northflank.com/product/deployments): Connect GitHub, GitLab, or Bitbucket repositories to automatically build and deploy every commit. Create deployment pipelines, promote releases across environments, automate approvals, and roll back deployments with a few clicks instead of managing CI/CD and GitOps tooling separately. - [**Preview environments for every pull request**](https://northflank.com/product/preview-environments): Automatically provision complete preview environments, including services and managed databases, for every pull request. Developers, reviewers, and AI coding assistants can validate changes in production-like environments before merging. - [**Managed infrastructure services**](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank): Provision PostgreSQL, MySQL, MongoDB, Redis, RabbitMQ, MinIO, object storage, jobs, cron jobs, and other supporting services from the same platform that runs your applications, eliminating the need for separate operational workflows. - [**Built-in networking**](https://northflank.com/docs/v1/application/network/networking-on-northflank), [**secrets**](https://northflank.com/docs/v1/application/secure/manage-secret-groups), and [**observability**](https://northflank.com/docs/v1/application/observe/observability-on-northflank): Every application includes managed networking, automatic TLS, centralized secrets management, logs, metrics, and deployment history without requiring additional Kubernetes tooling or manual configuration. - [**AI-native platform operations with Northflank Skills**](https://github.com/northflank/skills): AI coding assistants such as Claude Code, Codex, Cursor, and Gemini CLI can provision infrastructure, deploy applications, create preview environments, provision databases, troubleshoot deployments, and operate services directly from their agent sessions. These actions run through Northflank's platform APIs and remain subject to the organization's RBAC, audit logging, and security controls. - [**Secure runtime options for modern applications**](https://northflank.com/product/gpu-paas): Run traditional applications alongside [GPU workloads](https://northflank.com/product/gpu-paas), Firecracker microVMs, Kata Containers with Cloud Hypervisor, and gVisor from the same platform, allowing you to securely support AI agents, code execution, browser automation, and other isolation-sensitive workloads. - **Enterprise security and governance**: Centralize [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [SAML and OIDC SSO](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication), [audit logging](https://northflank.com/docs/v1/application/observe/audit-logs), secrets management, deployment permissions, and policy enforcement across every environment from a single control plane. - [**Built for enterprise scale**](https://northflank.com/enterprise): Standardize application delivery across multiple clouds, business units, and environments while giving developers a consistent experience regardless of where workloads run. Rather than assembling separate tools for CI/CD, GitOps, preview environments, secrets, databases, networking, observability, and governance, Northflank brings them together in a single platform. The result is a Vercel-like developer experience that works on infrastructure you control, without sacrificing the flexibility, security, or compliance requirements expected by enterprise organizations. ## FAQ: Vercel-like DX for on-prem deployments ### What is a Vercel-like developer experience? A Vercel-like developer experience focuses on making application deployment simple and self-service. Core capabilities include Git-based deployments, preview environments for every pull request, automatic networking and TLS, deployment pipelines, rollback, and managed infrastructure that allows developers to ship software without needing Kubernetes expertise. ### Can you get a Vercel-like developer experience on your own infrastructure? Yes. Modern enterprise platforms can deliver a similar developer experience while allowing applications to run on infrastructure you control. Platforms like [Northflank](https://northflank.com/) provide Git-based deployments, preview environments, managed services, deployment pipelines, and self-service workflows on Northflank Managed Cloud, through self-serve BYOC, or using a forward-deployed deployment for on-premises and regulated environments. ### What is the difference between BYOC and a forward-deployed deployment? With self-serve BYOC, applications run inside your own cloud account while [Northflank](https://northflank.com/) manages the platform experience. A forward-deployed deployment runs the platform entirely within your own environment, making it suitable for organizations with strict security, compliance, or air-gapped deployment requirements. ### Do developers need Kubernetes expertise? Not necessarily. A modern application platform should abstract infrastructure complexity behind Git-based workflows, deployment pipelines, managed networking, secrets management, and self-service infrastructure. This allows developers, data scientists, and AI coding assistants to deploy and manage applications without interacting directly with Kubernetes. ### Can AI coding assistants deploy applications? Yes. Platforms that support AI-native workflows allow tools such as Claude Code, Codex, Cursor, Gemini CLI, and other MCP-compatible assistants to provision infrastructure, deploy services, create preview environments, manage databases, and troubleshoot applications through governed workflows protected by RBAC and audit logging. ### Can Kubernetes provide a Vercel-like developer experience? Kubernetes provides the infrastructure orchestration layer, but it does not by itself provide the complete developer experience. Teams typically still need deployment automation, preview environments, deployment pipelines, secrets management, managed services, networking, observability, governance, and self-service workflows. ## Conclusion Vercel set the standard for modern application deployment by making it fast, self-service, and simple for developers. Enterprises can provide that same experience on their own infrastructure by choosing a platform with Git-based deployments, preview environments, deployment pipelines, managed services, networking, secrets management, governance, and self-service workflows. [Northflank](https://northflank.com/) brings these capabilities together across **Northflank Managed Cloud**, **self-serve BYOC**, and **forward-deployed deployments**. Developers and AI coding assistants get the same streamlined experience regardless of where applications run, while platform teams retain control over their infrastructure, security, and compliance. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to bring a Vercel-like developer experience to your own infrastructure.

How to choose an enterprise Kubernetes platform for AI workloads

2026-08-07T14:15:00.000Z

## TL;DR: How to choose an enterprise Kubernetes platform for AI workloads When evaluating an enterprise Kubernetes platform for AI workloads, focus on five capabilities: - **GPU infrastructure:** Support for modern GPUs, autoscaling, and efficient resource sharing. - **Secure workload isolation:** Protect AI agents and untrusted code with microVMs or equivalent isolation. - **AI framework support:** Run tools such as Ray, KubeFlow, MLflow, vLLM, and KServe without extensive customization. - **Developer experience:** Enable developers and AI coding assistants to deploy and manage workloads through self-service workflows. - **Enterprise capabilities:** Choose a platform with RBAC, audit logging, SSO, BYOC, and compliance features for production environments. > Northflank is an enterprise AI platform for building, deploying, and operating AI applications. Run [GPU workloads](https://northflank.com/product/gpu-paas), secure [microVM sandboxes](https://northflank.com/product/sandboxes), [managed Kubernetes](https://northflank.com/product/app-platform), [deployment pipelines](https://northflank.com/product/deployments), [preview environments](https://northflank.com/product/preview-environments), [managed databases](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), and [AI-native workflows](https://github.com/northflank/skills) from a single platform. Deploy on [Northflank Managed Cloud](https://northflank.com/features/managed-cloud), into your own cloud with [self-serve BYOC](https://northflank.com/features/bring-your-own-cloud), or using a [forward-deployed control plane](https://northflank.com/enterprise). [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > Choosing an enterprise Kubernetes platform for AI workloads involves more than comparing managed Kubernetes services. While platforms like Amazon EKS, Azure AKS, and Google Kubernetes Engine provide a solid Kubernetes foundation, enterprise AI workloads introduce additional requirements around GPU infrastructure, secure code execution, AI frameworks, and developer experience. This guide explains the key capabilities to evaluate when choosing an enterprise Kubernetes platform for AI workloads, compares how leading platforms meet those requirements, and highlights what to look for before deploying AI applications in production. ## What to evaluate when choosing an enterprise Kubernetes platform for AI workloads? Choosing an enterprise Kubernetes platform for AI workloads goes beyond evaluating Kubernetes itself. AI introduces new infrastructure, security, and operational requirements that many traditional platforms weren't designed to handle. When comparing platforms, evaluate the following areas. - **GPU infrastructure and scheduling:** Can the platform efficiently schedule GPU workloads, support multiple GPU types, GPU sharing (MIG or time-slicing), distributed training, and provide visibility into GPU utilization and costs? - **Workload isolation and security:** Does the platform support microVM technologies such as Firecracker or Kata Containers, or sandboxing with gVisor, for AI agents and workloads that execute untrusted or AI-generated code? - **AI framework compatibility:** Can you run frameworks such as Ray, KubeFlow, MLflow, vLLM, KServe, Triton, and Argo Workflows without significant customization or operational overhead? - **Inference and model serving:** Does the platform make it easy to deploy, scale, and operate production inference services with GPU autoscaling, managed networking, automatic TLS, and support for large models? - **Developer and AI agent experience:** Can developers, data scientists, and AI coding assistants provision infrastructure, deploy applications, create preview environments, and manage services through self-service workflows instead of Kubernetes administration? - **Enterprise operations and governance:** Does the platform provide BYOC, multi-cloud deployment, RBAC, SSO, audit logging, secrets management, compliance features, and deployment options for regulated or air-gapped environments? ## Comparing enterprise Kubernetes platforms for AI workloads Not all enterprise Kubernetes platforms are designed for AI. Some focus on cluster management, while others provide the infrastructure, security, and developer experience needed to build and operate AI applications. The table below compares the capabilities that matter most for enterprise AI workloads. | Capability | Northflank | OpenShift | Rancher | Spectro Cloud | VMware Tanzu | | --- | --- | --- | --- | --- | --- | | GPU workloads | Native | Supported | Supported | Supported | Supported | | MicroVM isolation | Firecracker, Kata, gVisor | Kata | External | External | External | | Managed Kubernetes | Yes | Yes | Yes | Yes | Yes | | Managed databases | Yes | No | No | Yes | Yes | | CI/CD & deployments | Native | Supported | Supported | Partial | Supported | | Preview environments | Yes | Partial | No | No | No | | AI coding assistant workflows | Native (Northflank Skills) | Yes | Partial | Yes | No | | Managed cloud | Yes | Yes | No | No | No | | BYOC | Yes (Self-serve) | Yes | Yes | Yes | Yes | | Forward-deployed control plane | Yes | Yes | Yes | Yes | Yes | ## Why teams choose Northflank for AI workloads Building AI applications on Kubernetes requires much more than running GPU-enabled containers. Teams need a platform that can provision infrastructure, securely execute AI-generated code, deploy inference services, automate application delivery, and provide developers and AI coding assistants with self-service access, all while meeting enterprise security and governance requirements. [Northflank](https://northflank.com/) combines these capabilities into a single enterprise platform. Deploy on Northflank Managed Cloud, into your existing cloud infrastructure with self-serve BYOC, or entirely within your own environment using a forward-deployed control plane. Whichever deployment model you choose, developers and AI coding assistants use the same platform to build, deploy, and operate AI applications. Northflank combines the capabilities enterprise AI teams typically assemble from multiple tools: - [**AI-ready GPU infrastructure**](https://northflank.com/product/gpu-paas): Deploy training and inference workloads on H100, H200, B200, A100, L40S, L4, MI300X, and other GPUs alongside your applications. GPU workloads, managed databases, and services all run from the same platform with unified networking, observability, and deployment workflows. - [**Secure AI sandboxing**](https://northflank.com/product/gpu-paas): Run AI agents, code interpreters, browser automation, and untrusted workloads using Firecracker microVMs, Kata Containers with Cloud Hypervisor, or gVisor. Choose the appropriate isolation model per workload instead of applying the same runtime across your entire cluster. - **AI-native workflows with** [**Northflank Skills**](https://github.com/northflank/skills): AI coding assistants such as Claude Code, Codex, Cursor, Gemini CLI, and other MCP-compatible tools can provision databases, deploy applications, create preview environments, configure infrastructure, troubleshoot deployments, and operate workloads using natural language. Every action is governed by your organization's RBAC, audit logging, and security policies. - **Complete developer platform:** Build and deploy directly from Git with automated CI/CD pipelines, deployment pipelines, [preview environments](https://northflank.com/product/preview-environments), [secrets management](https://northflank.com/docs/v1/application/secure/manage-secret-groups), [managed databases](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), object storage, jobs, cron jobs, [networking](https://northflank.com/docs/v1/application/network/networking-on-northflank), and [observability](https://northflank.com/docs/v1/application/observe/observability-on-northflank) without assembling multiple tools. - **Enterprise security and governance:** [Centralize RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [SAML and OIDC single sign-on](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication), [audit logging](https://northflank.com/docs/v1/application/observe/audit-logs), secrets management, network policies, and deployment permissions from a single control plane. Applications continue running inside your own cloud account while platform teams maintain visibility and control. - [**Multi-cloud and BYOC**](https://northflank.com/product/bring-your-own-cloud): Deploy the same applications across AWS, Azure, GCP, OCI, CoreWeave, or on-premises infrastructure using self-serve BYOC. Organizations can standardize on one platform while retaining ownership of their Kubernetes clusters and cloud resources. - [**Forward-deployed control plane**](https://northflank.com/enterprise): For organizations with strict security, compliance, or sovereignty requirements, Northflank can run entirely inside your own environment, making it suitable for regulated industries, government, healthcare, financial services, and defence. - **Proven production scale**: Northflank has demonstrated the ability to provision 100,000 concurrent microVM sandboxes in 24 seconds from a cold start with zero failures, achieving P99 allocation latency of 566 ms and P99 readiness of 733 ms in the [ComputeSDK 2026 Scale Invitational](https://platform.computesdk.com/scale-invitational/northflank). This enables enterprise AI teams to scale secure execution environments for agents and AI applications without compromising performance. Rather than adding another layer of operational complexity, Northflank brings AI infrastructure, application delivery, security, and developer experience together on a single platform. Developers and AI coding assistants use the same governed workflows to provision infrastructure, deploy applications, create environments, and operate AI workloads, while platform teams retain full control over security, compliance, and the underlying Kubernetes infrastructure. ## FAQ: Enterprise Kubernetes platforms for AI workloads ### What should I look for in an enterprise Kubernetes platform for AI workloads? Beyond standard Kubernetes capabilities, evaluate GPU scheduling, workload isolation, AI framework compatibility, inference serving, developer experience, and enterprise features such as RBAC, audit logging, BYOC, and compliance. AI workloads introduce security and operational requirements that traditional Kubernetes platforms often don't address out of the box. ### Which enterprise Kubernetes platform is best for AI workloads? The best platform depends on your requirements. If you primarily need Kubernetes lifecycle management, platforms such as OpenShift, Rancher, VMware Tanzu, and Spectro Cloud are established enterprise options. If you also need GPU workloads, secure AI sandboxes, deployment automation, managed services, and AI-native workflows from a single platform, Northflank provides these capabilities alongside Kubernetes. ### Why do AI workloads need stronger isolation than traditional applications? Many AI applications execute AI-generated code, user-submitted code, or autonomous agent actions at runtime. Standard containers share the host kernel, while microVM technologies such as Firecracker and Kata Containers provide each workload with its own kernel, reducing the impact of a compromised workload and improving isolation. ### Can AI coding assistants manage Kubernetes infrastructure? Yes. Modern AI coding assistants can provision infrastructure, deploy applications, create preview environments, and manage services when integrated with the appropriate platform. Northflank Skills enables tools such as Claude Code, Codex, Cursor, and Gemini CLI to perform these tasks through governed workflows protected by RBAC, audit logging, and enterprise security controls. ### Can I use my existing cloud infrastructure? Yes. Many enterprise platforms support Bring Your Own Cloud (BYOC), allowing workloads to run inside your existing AWS, Azure, GCP, OCI, or on-premises environment. This helps organizations retain ownership of their infrastructure while adopting a higher-level platform for application delivery and operations. ### Does Kubernetes include everything needed for enterprise AI? No. Kubernetes provides container orchestration, but most organizations still need deployment automation, CI/CD, managed databases, secrets management, preview environments, observability, RBAC, audit logging, GPU management, and developer self-service. Enterprise platforms build these capabilities on top of Kubernetes to provide a complete application platform. ## Conclusion Choosing an enterprise Kubernetes platform for AI workloads involves more than evaluating Kubernetes itself. GPU infrastructure, workload isolation, AI framework compatibility, inference serving, developer experience, and enterprise governance all play a critical role in determining whether a platform can support AI applications at scale. [Northflank](https://northflank.com/) brings these capabilities together in a single enterprise platform. Whether you deploy on Northflank Managed Cloud, into your own cloud through self-serve BYOC, or with a forward-deployed control plane, teams can build, deploy, and operate AI applications using the same platform. Developers and AI coding assistants work through governed workflows powered by Northflank Skills, while platform teams retain full control over security, compliance, and infrastructure. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30).

EKS vs AKS: which managed Kubernetes service should you choose?

2026-08-06T13:30:00.000Z

## TL;DR: EKS vs AKS - **Choose Amazon EKS** if you're already invested in AWS and want maximum flexibility with deep integration across the AWS ecosystem. - **Choose Azure AKS** if your organization relies on Microsoft services such as Entra ID, Azure DevOps, or GitHub and prefers a more managed Kubernetes experience. - **Neither service replaces a developer platform.** Both manage Kubernetes, but teams still need CI/CD, preview environments, secrets management, RBAC, and self-service workflows. Platforms like [Northflank](https://northflank.com/) provide those capabilities on top of EKS and AKS. > [Northflank](https://northflank.com/) lets teams deploy into existing EKS or AKS clusters using [self-serve BYOC](https://northflank.com/product/bring-your-own-cloud) while providing [Git-based deployments](https://northflank.com/product/deployments), [preview environments](https://northflank.com/product/preview-environments), deployment pipelines, [managed databases](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), [GPU workloads](https://northflank.com/product/gpu-paas), [secrets management](https://northflank.com/docs/v1/application/secure/security-on-northflank#secret-management), [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [audit logging](https://northflank.com/docs/v1/application/observe/audit-logs), and [AI-native workflows](https://github.com/northflank/skills) for AI coding assistants. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > Amazon Elastic Kubernetes Service (EKS) and Azure Kubernetes Service (AKS) are two of the most widely used managed Kubernetes platforms for running production workloads. Both remove the burden of managing the Kubernetes control plane while integrating tightly with their respective cloud ecosystems. This guide compares Amazon EKS and Azure AKS across pricing, networking, identity, autoscaling, upgrades, hybrid deployments, and operational overhead. It also explores what managed Kubernetes doesn't solve and why modern platform teams increasingly need a developer platform that supports both developers and AI coding assistants. ## EKS vs AKS: At a glance | Category | Amazon EKS | Azure AKS | | --- | --- | --- | | **Best for** | AWS-native organizations | Microsoft and Azure organizations | | **Control plane pricing** | $0.10/hour | Free tier or $0.10/hour (Standard) | | **Identity** | AWS IAM, IRSA, Pod Identity | Microsoft Entra ID | | **Networking** | AWS VPC CNI | Azure CNI or Kubenet | | **Autoscaling** | Karpenter, Cluster Autoscaler | Karpenter, Cluster Autoscaler, KEDA | | **Upgrade experience** | More manual | More automated | | **Hybrid deployments** | EKS Anywhere | Azure Arc | | **Serverless workloads** | AWS Fargate | Azure Container Instances | | **Best choice** | Organizations standardized on AWS | Organizations standardized on Azure | Neither platform is universally better. If you're already committed to AWS or Azure, the decision is usually straightforward. If you're evaluating both clouds, understanding the operational differences becomes much more important. ## What is Amazon EKS? Amazon Elastic Kubernetes Service (EKS) is AWS's managed Kubernetes platform. AWS manages the Kubernetes control plane, including the API server, etcd, availability, and upgrades, while customers manage worker nodes, networking, workloads, and supporting infrastructure. Because EKS closely follows upstream Kubernetes and integrates deeply with AWS services such as IAM, EC2, VPC, ECR, RDS, and CloudWatch, it's a popular choice for organizations already invested in the AWS ecosystem. ## What is Azure AKS? Azure Kubernetes Service (AKS) is Microsoft's managed Kubernetes platform. Like EKS, Microsoft operates the Kubernetes control plane while customers manage workloads and worker nodes. AKS integrates closely with Microsoft Entra ID, Azure networking, Azure Monitor, GitHub, and Azure DevOps, making it a natural choice for organizations standardized on Azure. AKS also provides a more opinionated operational experience, with additional automation around upgrades and cluster management. ## Comparing Amazon EKS and Azure AKS ### 1. Which platform is more cost-effective? | Category | Amazon EKS | Azure AKS | | --- | --- | --- | | **Control plane** | ~$0.10/hour | Free tier or ~$0.10/hour (Standard) | | **Infrastructure costs** | Compute, storage, networking, load balancers | Compute, storage, networking, load balancers | | **Pricing** | Paid control plane | Free or paid control plane | | **Best for** | Production AWS workloads | Development and Azure-native workloads | **Verdict:** AKS can reduce costs for development environments through its free control plane. For production workloads, infrastructure costs such as compute, storage, networking, and data transfer have a much greater impact than Kubernetes management fees. ### 2. Which platform has the better networking model? | Category | Amazon EKS | Azure AKS | | --- | --- | --- | | **Default networking** | AWS VPC CNI | Azure CNI | | **Alternative networking** | Third-party CNIs | Kubenet, Azure CNI | | **Primary advantage** | Deep AWS networking integration | Greater networking flexibility | | **Primary consideration** | Requires subnet planning | Simpler networking configuration | **Verdict:** EKS integrates tightly with AWS networking and VPC services, while AKS provides more networking options and generally requires less networking expertise to operate. ### 3. Which platform is easier to manage? | Category | Amazon EKS | Azure AKS | | --- | --- | --- | | **Identity** | AWS IAM, IRSA, Pod Identity | Microsoft Entra ID | | **Cluster upgrades** | More manual | More automated | | **Autoscaling** | Karpenter, Cluster Autoscaler | Karpenter, Cluster Autoscaler, KEDA | | **Operational experience** | Greater flexibility | Lower operational overhead | **Verdict:** Organizations already using AWS typically prefer EKS because it integrates naturally with IAM and other AWS services. Microsoft-centric organizations often find AKS simpler to operate thanks to Entra ID integration and additional automation. ### 4. Which platform is better for hybrid deployments? | Category | Amazon EKS | Azure AKS | | --- | --- | --- | | **Serverless workloads** | AWS Fargate | Azure Container Instances | | **Hybrid deployments** | EKS Anywhere | Azure Arc | | **Best for** | AWS hybrid environments | Microsoft hybrid environments | **Verdict:** Both platforms support hybrid and serverless deployments. The better choice usually depends on which cloud ecosystem your organization already uses. ## What should you consider when choosing between EKS and AKS? Both platforms deliver production-ready managed Kubernetes, so the decision usually comes down to your existing cloud strategy rather than Kubernetes itself. Choose **Amazon EKS** if you: - Already run most workloads on AWS - Depend heavily on AWS services such as IAM, VPC, EC2, RDS, or S3 - Want maximum flexibility when configuring Kubernetes. - Have an experienced platform engineering team managing AWS infrastructure. Choose **Azure AKS** if you: - Standardize on Microsoft Azure. - Use Microsoft Entra ID for identity and access management. - Prefer a more automated Kubernetes experience. - Rely on Azure DevOps, GitHub, or other Microsoft services. If your infrastructure is already standardized on one cloud provider, there is rarely a compelling reason to migrate purely because of Kubernetes. ## Comparing EKS, AKS, and Northflank Choosing a managed Kubernetes service is only one part of building an internal platform. Organizations still need deployment automation, developer self-service, secrets management, preview environments, governance, managed services, and operational tooling. Increasingly, they also need a platform that allows AI coding assistants to perform these same tasks securely alongside developers. | Capability | Amazon EKS | Azure AKS | Northflank | | --- | --- | --- | --- | | Managed Kubernetes | Yes | Yes | Deploys to existing Kubernetes through self-serve BYOC | | Internal developer platform | No | No | Yes | | Git-based deployments | External tooling | External tooling | Native | | CI/CD pipelines | External tooling | External tooling | Native | | Preview environments | External tooling | External tooling | Native | | Managed databases | External tooling | External tooling | Native | | Secrets management | Kubernetes or third party | Kubernetes or third party | Native | | Developer self-service | External tooling | External tooling | Native | | RBAC | Kubernetes RBAC | Kubernetes RBAC | Platform RBAC | | Audit logging | Cloud services | Cloud services | Platform-wide | | AI coding assistant support | External tooling | External tooling | Northflank Skills | While EKS and AKS provide managed Kubernetes, they leave much of the developer platform to external tooling. Northflank brings these capabilities together in a single platform, allowing both developers and AI coding assistants to provision infrastructure, deploy applications, create preview environments, and manage workloads through the same governed interface. ## Why teams choose Northflank on top of EKS or AKS Amazon EKS and Azure AKS manage Kubernetes, but they don't provide the complete platform developers use every day. Teams still need to build or integrate CI/CD, Git-based deployments, preview environments, managed databases, secrets management, RBAC, audit logging, and developer self-service before application teams can ship software efficiently. Northflank provides that platform layer while deploying workloads into your existing EKS or AKS clusters through self-serve BYOC. Your applications continue running inside your own AWS or Azure account, while developers and AI coding assistants use the same platform to provision infrastructure, deploy applications, create preview environments, manage databases, and operate workloads through governed workflows powered by [Northflank Skills](https://github.com/northflank/skills). Organizations choose Northflank because it combines: - [**Deploy into your existing EKS or AKS clusters**](https://northflank.com/product/bring-your-own-cloud): Continue using your existing cloud account, networking, and Kubernetes infrastructure while adding a complete developer platform on top. - [**Git-based deployments**](https://northflank.com/product/deployments) and [**CI/CD**](https://northflank.com/docs/v1/application/release/ci-cd-on-northflank): Build, deploy, and promote applications directly from Git with automated deployment pipelines, rollbacks, and environment promotion. - [**Preview environments**](https://northflank.com/product/preview-environments): Automatically create isolated preview environments for every pull request with temporary URLs and production-like infrastructure. - **Managed infrastructure services:** Provision [PostgreSQL, MySQL, MongoDB, Redis, RabbitMQ, MinIO](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), object storage, jobs, cron jobs, and [GPU workloads](https://northflank.com/product/gpu-paas) alongside your applications. - **Enterprise security and governance:** [Manage secrets](https://northflank.com/docs/v1/application/secure/security-on-northflank#secret-management), [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [SAML/OIDC SSO](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication), [audit logging](https://northflank.com/docs/v1/application/observe/audit-logs), [network policies](https://northflank.com/docs/v1/application/network/networking-on-northflank), and deployment permissions from a single control plane. - **AI-native platform operations with** [**Northflank Skills**](https://github.com/northflank/skills): Claude Code, Codex, Cursor, Gemini CLI, and other AI coding assistants can provision infrastructure, deploy applications, create preview environments, provision databases, troubleshoot deployments, manage secrets, configure networking, and operate workloads using natural language while remaining within your organization's RBAC, audit logging, and governance controls. - **Multi-cloud flexibility:** Deploy the same applications across [AWS, Azure, GCP, OCI, CoreWeave, or on-premises](https://northflank.com/product/bring-your-own-cloud) infrastructure while using the same platform and developer experience. - [**Self-serve BYOC**](https://northflank.com/product/bring-your-own-cloud): Applications run inside your own cloud account with no markup on the underlying compute, giving platform teams full ownership of their infrastructure. Rather than replacing EKS or AKS, Northflank extends them into a complete internal developer platform. Developers and AI coding assistants use the same platform to provision infrastructure, deploy applications, create preview environments, and manage production workloads, while platform teams retain full control over governance, security, and the underlying Kubernetes clusters. ## FAQ: EKS vs AKS ### Is Amazon EKS better than Azure AKS? Neither platform is universally better. Amazon EKS is typically the better choice for organizations already invested in AWS, while Azure AKS is often the better fit for organizations using Microsoft Azure and Entra ID. The right choice depends more on your existing cloud ecosystem than Kubernetes itself. ### Is AKS cheaper than EKS? AKS offers a free control plane tier for development and non-production workloads, while EKS charges for every control plane. For production environments, however, pricing is broadly similar because infrastructure costs such as compute, storage, and networking usually make up the majority of Kubernetes spending. ### Which is easier to manage? AKS generally provides a more opinionated and automated experience, particularly around upgrades and identity management. EKS offers greater flexibility but typically requires more Kubernetes and AWS expertise to operate effectively. ### Can I migrate between EKS and AKS? Yes. Both platforms run upstream Kubernetes, so most workloads can be migrated using standard Kubernetes manifests, Helm charts, or GitOps workflows. The biggest migration challenges are usually cloud-specific services such as networking, storage, identity, and load balancers rather than Kubernetes itself. ### Does EKS or AKS include CI/CD? No. Neither platform includes a complete application delivery platform. Teams typically integrate GitHub Actions, Azure DevOps, Argo CD, Jenkins, or similar tools to build and deploy applications. ### Do EKS and AKS support AI workloads? Yes. Both platforms support GPU-enabled Kubernetes nodes for AI training and inference workloads. The choice typically depends on which cloud provider already hosts your infrastructure rather than any major Kubernetes capability differences. ### Do I still need a platform on top of EKS or AKS? For many organizations, yes. While EKS and AKS manage Kubernetes, they don't provide everything developers need to build and ship software efficiently. Most engineering teams still require deployment pipelines, preview environments, secrets management, developer self-service, RBAC, audit logging, and managed services. Platforms like Northflank provide those capabilities while deploying applications into your existing Kubernetes clusters. ## Conclusion Amazon EKS and Azure AKS are both mature managed Kubernetes platforms. EKS is generally the better fit for AWS-native organizations that want maximum flexibility and deep integration with AWS services, while AKS is often the stronger choice for organizations standardized on Microsoft Azure and Entra ID. Choosing between EKS and AKS is ultimately a cloud decision. Building a developer platform is a separate one. Whether your Kubernetes clusters run on AWS or Azure, [Northflank](https://northflank.com/) adds the deployment automation, developer self-service, governance, preview environments, managed services, and AI-native workflows needed to turn managed Kubernetes into a complete internal developer platform. With [Northflank Skills](https://github.com/northflank/skills), developers and AI coding assistants can provision infrastructure, deploy applications, create environments, and operate workloads from the same governed platform. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to turn your existing EKS or AKS clusters into a complete internal developer platform.

What's the difference between a microVM and a container?

2026-08-06T13:15:00.000Z

## TL;DR: MicroVM vs container - **Use containers** when you're running trusted applications and want the fastest startup times with minimal resource overhead. - **Use microVMs** when you're running untrusted code, AI agents, multi-tenant workloads, or applications that require stronger workload isolation. - **You don't have to choose one or the other.** Platforms like [Northflank](https://northflank.com/) let you run standard containers and microVM sandboxes side by side, applying the right isolation model to each workload. > [Northflank](https://northflank.com/) is the runtime platform for AI-native companies. Run standard [containers](https://northflank.com/deploy/run-persistent-and-ephemeral-docker-containers), [Firecracker, Kata Containers with Cloud Hypervisor, and gVisor](https://northflank.com/product/sandboxes) alongside [deployment pipelines](https://northflank.com/product/deployments), [preview environments](https://northflank.com/product/preview-environments), managed databases, [GPU workloads](https://northflank.com/product/gpu-paas), [secrets management](https://northflank.com/docs/v1/application/secure/manage-secret-groups), [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [audit logging](https://northflank.com/docs/v1/application/observe/audit-logs), [self-serve BYOC](https://northflank.com/product/bring-your-own-cloud), and [Northflank Skills](https://github.com/northflank/skills) for AI coding assistants. Deploy trusted applications and isolate AI agents from the same platform. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > Containers and microVMs both isolate applications from one another, but they do so in very different ways. The biggest difference is that containers share the host kernel, while each microVM runs its own kernel. That architectural difference affects almost everything else, including security, startup time, resource usage, and the types of workloads each technology is best suited for. This guide compares containers and microVMs, explains when to use each, and shows why many modern platforms use both together. ## What is the difference between a microVM and a container? Both containers and microVMs package applications into isolated execution environments, but they create that isolation differently. [**Containers**](https://northflank.com/deploy/run-persistent-and-ephemeral-docker-containers) isolate applications using Linux namespaces and cgroups while sharing the host kernel. This makes them extremely lightweight, allowing applications to start in milliseconds with very little overhead. [**MicroVMs**](https://northflank.com/product/sandboxes) add another isolation boundary by running every workload inside its own lightweight virtual machine with a dedicated kernel. Instead of sharing the host operating system, each workload runs independently using hardware virtualization. For many production applications, containers provide more than enough isolation. For workloads that execute untrusted code, AI-generated code, or applications from multiple tenants, microVMs provide significantly stronger security guarantees. ## MicroVM vs container | Feature | Container | MicroVM | | --- | --- | --- | | Isolation | Shared host kernel | Dedicated kernel per workload | | Security boundary | Linux namespaces and cgroups | Hardware virtualization | | Startup time | Milliseconds | Typically under 200 ms | | Memory overhead | Very low | Slightly higher | | Performance | Near native | Near native with minimal virtualization overhead | | Best for | Trusted applications, microservices, CI/CD | AI agents, code execution, multi-tenant platforms, sandboxing | | **Example technologies** | Docker, containerd | Firecracker, Kata Containers | Neither technology is universally better. Many organizations run both, using containers for trusted services and microVMs for higher-risk workloads. The right choice depends on your threat model, performance requirements, and the workloads you're running. ## How containers work [Containers](https://northflank.com/deploy/run-persistent-and-ephemeral-docker-containers) package an application together with its runtime, libraries, and dependencies, while sharing the host operating system's kernel. Linux namespaces isolate processes, networking, and filesystems, while cgroups control CPU, memory, and other resource limits. This allows hundreds of containers to run efficiently on the same machine without each requiring its own operating system. Because every container shares the same kernel, containers are extremely fast to start and use very little memory. This makes them the standard choice for microservices, web applications, APIs, CI/CD pipelines, and most cloud-native workloads. The trade-off is security. If an attacker exploits a kernel vulnerability or successfully performs a container escape, they may gain access to the host operating system and potentially other workloads running on the same machine. For trusted workloads that you control, this risk is generally acceptable. For untrusted code, the shared kernel becomes a much more important consideration. ## How microVMs work [MicroVMs](https://northflank.com/deploy/run-persistent-and-ephemeral-docker-containers) are lightweight virtual machines designed to provide stronger isolation while keeping startup times and resource overhead low. Unlike containers, every microVM runs its own Linux kernel. Applications communicate with that kernel instead of the host operating system, creating a hardware-enforced isolation boundary using virtualization technologies such as Intel VT-x and AMD-V. If a workload is compromised, the attacker remains confined to that individual microVM rather than gaining direct access to the host kernel. This significantly reduces the blast radius of a compromised workload, making microVMs particularly well suited to workloads that execute code from untrusted sources. Although microVMs require slightly more memory and take a little longer to start than containers, technologies such as Firecracker have reduced that overhead to the point where microVMs can boot in well under a second while consuming only a few megabytes of additional memory. ## Common workload isolation technologies Different isolation technologies offer different trade-offs between security, compatibility, and performance. ### 1. Firecracker Firecracker is an open-source microVM monitor originally developed by AWS. It uses hardware virtualization to run each workload inside its own lightweight virtual machine with a dedicated kernel, providing strong isolation with minimal startup time and memory overhead. **Best for:** Serverless platforms, AI agents, code execution, browser automation, and short-lived workloads. ### 2. Kata Containers Kata Containers run OCI-compatible containers inside lightweight virtual machines using hypervisors such as Cloud Hypervisor. Developers continue using Docker and Kubernetes as usual while each container benefits from hardware-level isolation. **Best for:** Kubernetes workloads that need stronger isolation without changing existing container workflows. ### 3. gVisor gVisor is a container sandbox rather than a microVM. Instead of relying on hardware virtualization, it implements a userspace kernel that intercepts application system calls before they reach the host kernel. This provides stronger isolation than standard containers while maintaining broad container compatibility. **Best for:** Workloads that need more isolation than standard containers without using hardware virtualization. ### Run containers and microVMs from one platform Different workloads require different levels of isolation. [Northflank](https://northflank.com/product/sandboxes) supports standard containers, Firecracker microVMs, Kata Containers with Cloud Hypervisor, and gVisor from the same platform, allowing teams to choose the right runtime for each workload without managing separate infrastructure. **Get started with Northflank sandboxes** - [Sandboxes on Northflank: overview and concepts](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank): architecture overview and core sandbox concepts - [Deploy sandboxes on Northflank: step-by-step deployment guide](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-on-northflank): step-by-step deployment guide - [Deploy sandboxes in your cloud: BYOC deployment guide](https://northflank.com/docs/v1/application/sandboxes/deploy-sandboxes-in-your-cloud): run microVMs inside your own VPC - [Create a sandbox with the SDK: programmatic sandbox creation](https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank#create-sandboxes-with-the-sdk): programmatic sandbox creation via the Northflank JS client - See [how to spin up a secure code sandbox & microVM in seconds with Northflank](https://northflank.com/blog/how-to-spin-up-a-secure-code-sandbox-and-microvm-in-seconds-with-northflank-firecracker-gvisor-kata-clh). [Get started (self-serve)](https://app.northflank.com/signup), or [book a session with an engineer](https://cal.com/team/northflank/northflank-demo?duration=30) if you have specific infrastructure or compliance requirements. ## When should you use containers? Containers are the default choice for most cloud-native applications because they offer excellent performance with very little overhead. They're ideal when you control the code that's running and don't need an additional hardware isolation boundary. Use containers for: - Web applications and APIs - Microservices - Background workers and scheduled jobs - Internal developer tools - CI/CD pipelines - Managed databases and supporting infrastructure For these workloads, sharing the host kernel is generally an acceptable trade-off because the applications are trusted, resource efficiency is high, and startup times are measured in milliseconds. ## When should you use microVMs? MicroVMs become the better choice when the workload cannot be fully trusted or when stronger isolation is required. Instead of relying solely on operating system isolation, each workload runs inside its own lightweight virtual machine with a dedicated kernel. This significantly reduces the impact of a compromised workload and makes microVMs well suited to modern AI and multi-tenant platforms. Use microVMs for: - AI agents executing code - Code interpreters - User-submitted code - Browser automation - Multi-tenant SaaS platforms - Sandbox environments - Security-sensitive workloads As AI-generated code becomes more common, organizations are increasingly using microVMs to isolate code execution without sacrificing developer productivity. ## Containers and microVMs work together Containers and microVMs aren't competing technologies. Many modern platforms use both together, applying different isolation models depending on the workload. Developers continue building and deploying standard OCI-compatible container images, while the platform decides how those workloads are isolated. Trusted applications can run as standard containers for maximum efficiency, while AI agents, code execution environments, browser automation, and other untrusted workloads can run inside microVMs for stronger isolation. This approach lets organizations keep their existing Docker and Kubernetes workflows while applying additional protection only where it's needed. Rather than choosing between containers and microVMs, teams can use both within the same platform based on the security requirements of each workload. Northflank follows this approach by supporting standard containers alongside Firecracker, Kata Containers with Cloud Hypervisor, and gVisor from the same control plane. Teams can apply the appropriate isolation model per workload without managing separate infrastructure or changing their deployment workflows. ## How Northflank handles workload isolation ### What is Northflank? Northflank is the runtime platform for AI-native companies for building, deploying, and operating applications, AI workloads, and sandbox environments. Run standard [containers](https://northflank.com/deploy/run-persistent-and-ephemeral-docker-containers), [Firecracker microVMs, Kata Containers with Cloud Hypervisor, and gVisor](https://northflank.com/product/sandboxes) from the same control plane alongside [deployment pipelines](https://northflank.com/product/deployments), [preview environments](https://northflank.com/product/preview-environments), [managed databases](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), object storage, [GPU workloads](https://northflank.com/product/gpu-paas), [secrets management](https://northflank.com/docs/v1/application/secure/manage-secret-groups), [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [audit logging](https://northflank.com/docs/v1/application/observe/audit-logs), [self-serve BYOC](https://northflank.com/product/bring-your-own-cloud), and [Northflank Skills](https://github.com/northflank/skills) for AI coding assistants. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). Different workloads have different security requirements. A production API may only need standard container isolation, while an AI agent executing arbitrary code may require a dedicated microVM. Rather than forcing every workload to use the same isolation model, Northflank supports multiple isolation technologies within the same platform. Organizations can apply the isolation model that best fits each workload: - **Standard containers** for trusted application workloads where performance and density are the priority. - **gVisor** for workloads that benefit from stronger isolation than standard containers through a userspace kernel. - **Kata Containers with Cloud Hypervisor** for OCI-compatible containers running inside lightweight virtual machines. - **Firecracker microVMs** for AI agents, code execution, browser automation, and sandbox environments requiring hardware-level isolation. Because every runtime is managed through the same control plane, developers don't need separate infrastructure for different isolation models. Git-based deployments, deployment pipelines, preview environments, managed databases, object storage, GPU workloads, secrets management, RBAC, audit logging, networking, self-serve BYOC, and Northflank Skills work consistently regardless of the runtime selected. **Proven at scale:** In the [ComputeSDK 2026 Scale Invitational](https://platform.computesdk.com/scale-invitational/northflank), Northflank provisioned **100,000 concurrent microVM sandboxes in 24 seconds** from a cold start with **zero failures**, achieving **P99 allocation latency of 566 ms** and **P99 readiness of 733 ms**. Developers and AI coding assistants can securely provision infrastructure, execute code, deploy applications, create preview environments, and manage workloads from the same governed platform. ## FAQ: MicroVM vs container ### Are microVMs more secure than containers? Generally, yes. Containers share the host kernel, while microVMs provide each workload with its own kernel, creating a stronger isolation boundary. For trusted applications, containers are usually sufficient. For untrusted or AI-generated code, microVMs provide additional protection. ### Are microVMs slower than containers? MicroVMs have slightly higher startup times and memory overhead because each workload boots its own kernel. Modern technologies such as Firecracker have reduced this overhead significantly, with startup times typically below 200 milliseconds. ### Can I run Docker containers inside a microVM? Yes. Technologies such as Kata Containers run standard OCI-compatible container images inside lightweight virtual machines, allowing teams to keep existing Docker and Kubernetes workflows while gaining stronger isolation. ### Do AI agents need microVMs? If an AI agent executes shell commands, runs code, or launches code interpreters, microVMs are generally the safer option because they isolate each execution from the host and other workloads. ### Which is better for Kubernetes? Most Kubernetes workloads run perfectly well in standard containers. However, platforms such as Kata Containers allow specific workloads to run inside microVMs when additional isolation is required, making it possible to mix both approaches within the same Kubernetes cluster. ## Conclusion Containers and microVMs solve different problems. Containers provide lightweight, efficient isolation for trusted workloads, while microVMs add a dedicated kernel and hardware-level isolation for workloads that execute untrusted code, AI agents, or multi-tenant applications. The best platforms don't force you to choose one or the other. They let you apply the right isolation model for each workload. [Northflank](https://northflank.com/) supports standard containers, Firecracker, Kata Containers with Cloud Hypervisor, and gVisor from the same control plane, allowing teams to balance performance, security, and operational simplicity without managing separate infrastructure. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ## Related articles - [**Containers vs virtual machines**](https://northflank.com/blog/containers-vs-virtual-machines): How containers and VMs compare on isolation, startup time, memory overhead, and when to use each. - [**What is a microVM?**](https://northflank.com/blog/what-is-a-microvm): A deep dive into how microVMs work, how they compare to containers and VMs, and when to use them. - [**Firecracker vs Docker**](https://northflank.com/blog/firecracker-vs-docker): Key differences in isolation model, startup time, and security boundaries, and when to use each. - [**What is a sandbox?**](https://northflank.com/blog/what-is-a-sandbox-and-isolation-technologies): How sandbox isolation technologies work and what makes something a sandbox. - [**Best enterprise AI sandbox platforms**](https://northflank.com/blog/best-enterprise-ai-sandbox-platforms): A comparison of enterprise sandbox platforms covering SOC 2, HIPAA, BYOC, and microVM isolation.

What is the best IDP for highly regulated industries?

2026-08-05T16:00:00.000Z

## TL;DR: Best internal developer platform (IDP) for highly regulated industries - **The best internal developer platform for regulated industries prioritizes control over convenience.** Deployment architecture, workload isolation, identity management, and auditability often determine whether a platform can be adopted. - **Most internal developer platforms stop at BYOC.** Regulated organizations often require a forward-deployed control plane, complete audit logging, runtime isolation, and enterprise identity integration to satisfy security and compliance requirements. - **Northflank combines an internal developer platform with enterprise deployment options**, including [self-serve BYOC](https://northflank.com/product/bring-your-own-cloud), [forward-deployed control planes](https://northflank.com/enterprise), [microVM sandbox isolation](https://northflank.com/product/sandboxes), [enterprise SSO](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication), [audit logging](https://northflank.com/docs/v1/application/observe/audit-logs), [AI-native workflows](https://github.com/northflank/skills), and [managed infrastructure](https://northflank.com/features/managed-cloud) in a single platform. > [Northflank](https://northflank.com/) helps public companies, financial institutions, healthcare providers, and government organizations build secure internal developer platforms with self-serve BYOC, forward-deployed control planes, sandbox environments, deployment pipelines, [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), audit logging, and AI-native workflows. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > Healthcare providers, financial institutions, government agencies, defence organizations, and other regulated enterprises evaluate internal developer platforms differently from most organizations. Developer experience matters, but security, governance, compliance, and deployment architecture often determine whether a platform can be adopted in the first place. This guide explains what regulated organizations should look for in an internal developer platform, how deployment models affect security and compliance, and why capabilities such as workload isolation, audit logging, identity management, and enterprise AI workflows have become essential when building software in regulated environments. ## Why regulated industries need a different kind of internal developer platform Most internal developer platforms are designed to help engineering teams move faster through self-service infrastructure, automated deployments, and standardized workflows. While those capabilities are valuable, regulated organizations also need to satisfy strict security, compliance, and operational requirements that extend well beyond developer productivity. The platform itself becomes part of the organization's security boundary. How workloads are isolated, where the control plane runs, how secrets are managed, whether every action is auditable, and how developers and AI coding assistants access infrastructure can all affect compliance. As a result, deployment architecture and governance often matter just as much as features like Kubernetes support, CI/CD, or developer self-service. ## What to look for in an internal developer platform for regulated industries Developer experience is only one part of the evaluation process. Regulated organizations also need to consider how the platform handles deployment architecture, governance, security, and compliance. 1. **Flexible deployment architecture:** The best platforms support managed SaaS, self-serve BYOC, and forward-deployed control planes, allowing organizations to choose where workloads and the control plane run. This is especially important for organizations with strict data residency, air-gapped, or regulatory requirements. 2. **Identity and access management:** Look for enterprise SSO, fine-grained RBAC, and least-privilege access controls across organizations, projects, and environments. These capabilities help ensure developers only have access to the infrastructure and environments they need. 3. **Audit logging:** Every deployment, configuration change, permission update, and secret access should be recorded. Comprehensive audit logs simplify compliance reporting, support security investigations, and provide a complete history of platform activity. 4. **Secrets management:** Credentials should be stored securely and injected into applications at build or runtime rather than committed to source code. Centralized secrets management also makes credential rotation and access control easier to manage. 5. **Runtime isolation:** Workloads handling sensitive data or executing AI-generated code should be isolated from one another. Technologies such as microVMs provide stronger isolation than traditional containers, helping reduce security risks. 6. **Network security:** Services should only communicate with the systems they are explicitly allowed to access. Network isolation and default-deny policies help reduce unnecessary exposure and limit lateral movement across environments. 7. **Enterprise AI readiness:** AI coding assistants are increasingly provisioning infrastructure, deploying applications, and managing environments. An internal developer platform should expose these workflows securely to both developers and AI agents without compromising governance or compliance. ## Comparing deployment models for regulated industries Most internal developer platforms support one or more deployment models, but not every deployment model satisfies the requirements of regulated industries. Understanding the differences between managed SaaS, BYOC, and forward-deployed control planes can make it much easier to evaluate which platform fits your security and compliance requirements. | Capability | Managed SaaS | BYOC | Forward-deployed control plane | | --- | --- | --- | --- | | Workloads run inside your cloud | No | Yes | Yes | | Control plane inside your environment | No | No | Yes | | External platform dependency | High | Moderate | None | | Air-gapped deployments | No | Limited | Yes | | Data residency | Vendor managed | Customer managed | Customer managed | | Best for | Standard enterprise workloads | Security-conscious organizations | Highly regulated industries | For many regulated organizations, supporting BYOC is only part of the requirement. A forward-deployed control plane can provide the additional control, isolation, and data residency needed for the most sensitive workloads. ## Comparing leading internal developer platforms for regulated industries Deployment architecture is only one part of the evaluation. Regulated organizations should also compare how internal developer platforms handle governance, runtime security, deployment flexibility, and enterprise operations. | Capability | Backstage | Port | Humanitec | Harness | Northflank | | --- | --- | --- | --- | --- | --- | | Developer portal | Yes | Yes | Limited | Yes | Yes | | Managed SaaS | No | Yes | Yes | Yes | Yes | | Self-serve BYOC | No | No | Partial | Partial | Yes | | Forward-deployed control plane | No | No | No | Yes | Yes | | Enterprise SSO | Via integrations | Yes | Yes | Yes | Yes | | Audit logging | Via integrations | Yes | Yes | Yes | Yes | | Runtime isolation | Depends on execution platform | Depends on execution platform | Depends on execution platform | Depends on execution platform | Built-in microVM sandbox isolation | | AI agent workflows | External integrations | External integrations | External integrations | External integrations | Northflank Skills | | Built-in deployment platform | No | No | No | Yes | Yes | While all of these platforms support modern platform engineering workflows, they differ significantly in deployment flexibility, runtime isolation, and execution capabilities. Organizations with strict security or compliance requirements should evaluate not only the developer experience, but also where the platform runs, how workloads are isolated, and whether AI-assisted workflows operate within the same governance model. ## How Northflank meets these requirements Northflank is designed for organizations that need enterprise-grade security without sacrificing developer self-service. Instead of combining multiple products for deployment, governance, and infrastructure management, Northflank brings those capabilities together in a single platform. ### What is Northflank? [Northflank](https://northflank.com/) is an internal developer platform for building, deploying, and operating modern applications. The platform combines developer self-service, [Git-based deployments](https://northflank.com/product/deployments), [preview environments](https://northflank.com/product/preview-environments), [managed databases](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), deployment pipelines, [sandbox environments](https://northflank.com/product/sandboxes), [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [audit logging](https://northflank.com/docs/v1/application/observe/audit-logs), [AI-native workflows](https://github.com/northflank/skills), and [self-serve BYOC](https://northflank.com/product/bring-your-own-cloud) within a single internal developer platform. Organizations can run Northflank as a [managed cloud](https://northflank.com/features/managed-cloud) platform, deploy into their own cloud with [self-serve BYOC](https://northflank.com/product/bring-your-own-cloud), or use a [forward-deployed](https://northflank.com/enterprise) control plane for environments that require complete infrastructure ownership. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ## Why organizations choose Northflank Northflank is designed for organizations that need enterprise-grade security without sacrificing developer productivity. Instead of stitching together separate tools for deployment, infrastructure, governance, and self-service, Northflank brings these capabilities together in a single internal developer platform. - **Deploy on your terms:** Run Northflank as a [managed cloud](https://northflank.com/features/managed-cloud) platform, deploy into your own cloud with [self-serve BYOC](https://northflank.com/product/bring-your-own-cloud), or use a [forward-deployed control plane](https://northflank.com/enterprise) when workloads and platform services must remain entirely within your environment. - **Meet enterprise security requirements:** Secure applications with [enterprise SSO](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication), [fine-grained RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [audit logging](https://northflank.com/docs/v1/application/observe/audit-logs), [secrets management](https://northflank.com/docs/v1/application/secure/security-on-northflank#secret-management), and [network isolation](https://northflank.com/docs/v1/application/network/networking-on-northflank), helping teams satisfy internal security policies and regulatory requirements. - **Protect sensitive workloads with stronger isolation:** Execute AI-generated code and sensitive applications using [microVM sandbox](https://northflank.com/product/sandboxes) environments powered by Firecracker, Kata Containers or gVisor for stronger runtime isolation than traditional containers. - **Reduce platform complexity:** [Deploy applications](https://northflank.com/product/deployments), [databases](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), jobs, [preview environments](https://northflank.com/product/preview-environments), object storage, [GPU workloads](https://northflank.com/product/gpu-paas), and deployment pipelines from a single control plane instead of integrating and maintaining multiple products. - **Support AI-assisted development:** Through [Northflank Skills](https://github.com/northflank/skills), developers and AI coding assistants such as Claude Code, Codex, Cursor, and Gemini CLI can provision infrastructure, create preview environments, deploy applications, and manage workloads using natural language while remaining within the platform's governance controls. - **Build for highly regulated environments:** Whether you're [deploying into your own cloud](https://northflank.com/product/bring-your-own-cloud), operating a [forward-deployed control plane](https://northflank.com/enterprise), or supporting air-gapped and compliance-sensitive workloads, Northflank provides the deployment flexibility and governance controls needed for regulated industries. Rather than evaluating each capability separately, regulated organizations should consider how well an internal developer platform combines them into a single operational model. Together, these capabilities allow regulated organizations to standardize application delivery, reduce operational complexity, and provide both developers and AI coding assistants with secure self-service access to infrastructure from a single platform. ## FAQ: Best internal developer platform for regulated industries ### What is the best internal developer platform for regulated industries? The best platform balances developer productivity with deployment flexibility, workload isolation, auditability, identity management, and compliance. Organizations should evaluate deployment architecture as carefully as platform features. ### Is BYOC enough for regulated industries? BYOC satisfies many security requirements by keeping workloads inside your own cloud account. Some organizations also require a forward-deployed control plane so the platform itself remains inside their environment. ### Why does workload isolation matter? Runtime isolation helps reduce the impact of compromised workloads and is increasingly important when running AI-generated or untrusted code. ### Can AI coding assistants be used in regulated environments? Yes, provided they operate through secure platform controls with RBAC, audit logging, and workload isolation rather than unrestricted infrastructure access. ### What compliance features should an internal developer platform provide? Common requirements include enterprise SSO, RBAC, audit logging, secrets management, secure deployment pipelines, workload isolation, and deployment options that support organizational compliance requirements. ### Can regulated industries use SaaS internal developer platforms? Yes, many can. However, organizations with strict security, data residency, or air-gapped requirements often need deployment options such as BYOC or a forward-deployed control plane to keep workloads and platform services within their own environment. ### What is the difference between BYOC and a forward-deployed control plane? **BYOC** keeps workloads inside your cloud account, while a **forward-deployed control plane** keeps both the workloads and the platform itself inside your environment, eliminating external platform dependencies. ## Conclusion The best internal developer platform for regulated industries isn't simply the one with the most features. It's the one that provides the deployment flexibility, governance, and security controls needed to satisfy regulatory requirements while giving developers a modern self-service experience. Platforms like Northflank combine these capabilities into a single platform, allowing organizations to modernize software delivery without compromising control, compliance, or operational security. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30).

Backstage vs Port: Which internal developer portal should you choose?

2026-08-04T14:30:00.000Z

## TL;DR: Backstage vs Port - **Choose Backstage** if you want maximum flexibility and have the engineering resources to build and maintain your own internal developer portal. - **Choose Port** if you want a managed developer portal with faster time to value and less operational overhead. - **Neither platform is an execution layer.** Both rely on external infrastructure to build, deploy, and operate applications. Platforms like [Northflank](https://northflank.com/) combine the developer portal, execution platform, CI/CD, preview environments, managed databases, secrets management, and AI-native workflows in a single platform. > Northflank combines developer self-service, [Git-based deployments](https://northflank.com/product/deployments), [preview environments](https://northflank.com/product/preview-environments), [managed databases](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), [secrets management](https://northflank.com/docs/v1/application/secure/security-on-northflank#secret-management), deployment pipelines, [sandbox environments](https://northflank.com/product/sandboxes), [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [audit logging](https://northflank.com/docs/v1/application/observe/audit-logs), [self-serve BYOC](https://northflank.com/product/bring-your-own-cloud), and [Northflank Skills](https://github.com/northflank/skills) for Claude Code, Codex, Cursor, Gemini CLI, and other AI coding assistants, allowing both developers and AI agents to provision infrastructure and manage deployments from the same platform. [Get started](https://app.northflank.com/signup) (self-serve) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > Backstage and Port are two of the most popular internal developer portals, but they take very different approaches. Backstage is an open-source framework that gives platform teams complete control over the developer experience, while Port is a managed SaaS platform focused on faster adoption with less operational overhead. This guide compares Backstage and Port across customization, self-service workflows, developer experience, maintenance, pricing, and total cost of ownership. It also explores an important question many comparisons overlook: what actually builds, deploys, and runs applications after a developer clicks **Deploy** or **Create service**. ## What is Backstage? Backstage is an open-source framework for building internal developer portals. Created by Spotify and now a CNCF graduated project, it gives platform teams complete control over the developer experience through a customizable portal. It includes a software catalog, Software Templates for scaffolding new services, TechDocs for documentation-as-code, Tech Insights for engineering scorecards, and a large plugin ecosystem covering Kubernetes, GitHub, ArgoCD, Grafana, PagerDuty, and many other tools. The trade-off is that Backstage is another application your team owns. You're responsible for deploying it, maintaining plugins, building integrations, and keeping everything up to date. It also focuses on the developer portal itself rather than the infrastructure behind it. Building, deploying, provisioning, and operating workloads still depends on another platform. ## What is Port? Port is a managed internal developer portal that focuses on delivering self-service workflows without the operational overhead of running your own portal. Instead of building and maintaining the platform yourself, you configure it through Port's UI and APIs. Port provides a software catalog built around Blueprints, self-service actions, engineering scorecards, developer dashboards, and integrations with GitHub, GitLab, Kubernetes, Terraform, AWS, Azure, GCP, PagerDuty, Datadog, and other engineering tools. The trade-off is flexibility. Because Port is a managed SaaS product, customization happens within the platform rather than through custom application code. Like Backstage, it also focuses on the portal layer. Actions such as deploying applications, provisioning databases, or managing infrastructure still rely on an external execution platform. ## Backstage vs Port: Which should you choose? Both Backstage and Port improve the developer experience, but they solve different problems. Backstage is a framework for building your own internal developer portal, while Port is a managed SaaS product. A third option is adopting an internal developer platform that includes a developer portal alongside the infrastructure needed to build, deploy, and operate applications. | Category | Backstage | Port | Northflank | | --- | --- | --- | --- | | **Product type** | Open-source developer portal framework | Managed internal developer portal | Internal developer platform with integrated developer portal | | **Deployment model** | Self-hosted | SaaS | Managed SaaS or self-serve BYOC | | **Time to value** | Months | Days to weeks | Minutes | | **Operational overhead** | High | Low | Low | | **Customization** | Unlimited | High within the platform | Platform configuration, APIs, and extensibility | | **Execution platform** | External platform required | External platform required | Included | | **CI/CD** | External integration | External integration | Native | | **Preview environments** | External integration | External integration | Native | | **Managed databases** | External integration | External integration | Native | | **Best for** | Organizations with mature platform engineering teams | Teams that want a managed developer portal | Teams that want a unified platform for building, deploying, and operating applications | **Looking for a broader comparison?** See [**Top internal developer portals**](https://northflank.com/blog/top-internal-developer-portals) for a comparison of Backstage, Port, Cortex, Humanitec, Northflank, and other leading internal developer platforms. **If your organization** has a mature platform engineering team and wants complete control over the developer experience, Backstage offers the greatest flexibility through custom plugins, integrations, and documentation workflows. **If your priority is delivering** a developer portal quickly with minimal operational overhead, Port is usually the better choice. **If you're looking for both** a developer portal and the platform that builds, deploys, and operates applications, an integrated platform like [Northflank](https://northflank.com/) removes the need to assemble and maintain those layers separately. ## The execution layer behind the portal Choosing an internal developer portal is only part of the decision. Whether you choose Backstage or Port, the portal isn't what builds containers, deploys applications, provisions databases, or runs workloads. When a developer clicks **Create service**, **Deploy**, or **Provision database**, the portal hands that request to an underlying execution platform. That execution platform turns self-service requests into running infrastructure. It handles deployments, environments, networking, secrets, scaling, governance, and everything else required to operate applications in production. Increasingly, those requests don't just come from developers. AI coding assistants are also provisioning environments, deploying services, responding to CI/CD failures, and managing infrastructure as part of the software delivery process. An execution platform should expose the same capabilities to both developers and AI agents. This separation works well for organizations that already have Kubernetes platforms, CI/CD pipelines, or Infrastructure as Code workflows. The trade-off is operational complexity, since every integration becomes another system to configure, secure, and maintain. Some teams instead choose a platform where the developer portal and execution layer are part of the same product, reducing the number of integrations needed to deliver a complete internal developer platform. ## An integrated alternative (Northflank) [Northflank](https://northflank.com/) combines the developer portal and execution layer in a single platform. Developers can discover services, provision infrastructure, deploy applications, create preview environments, manage databases, and operate workloads from the same control plane instead of switching between separate portal and deployment platforms. The same platform capabilities are also available to AI coding assistants through [Northflank Skills](https://github.com/northflank/skills). Instead of relying on custom scripts or API integrations, Claude Code, Codex, Cursor, Gemini CLI, and other AI agents can provision infrastructure, create preview environments, configure deployments, and manage applications using natural language. ### What is Northflank? [Northflank is an internal developer platform](https://northflank.com/product/idp) for building, deploying, and operating modern applications. Applications, [AI workloads](https://northflank.com/product/gpu-paas), [deployment pipelines](https://northflank.com/product/deployments), [preview environments](https://northflank.com/product/preview-environments), [managed databases](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), object storage, [sandbox environments](https://northflank.com/product/sandboxes), networking, and developer self-service all run within the same platform. **** Whether you're replacing multiple platform engineering tools or building an internal developer platform from scratch, Northflank provides the infrastructure needed to move from source code to production. Get started (self-serve) or book a demo. > **Need to run everything inside your own cloud?** [Northflank's self serve BYOC](https://northflank.com/product/bring-your-own-cloud) and forward deployed control planes let teams deploy the same platform into AWS, Azure, GCP, Oracle, CoreWeave, or on premises infrastructure while keeping the same developer experience. > From the moment a developer creates a new service, Northflank provides the platform capabilities needed to build, deploy, operate, and govern applications throughout their lifecycle. ## **Comparing the platform capabilities** | Capability | Backstage | Port | Northflank | | --- | --- | --- | --- | | Developer portal | Yes | Yes | Yes | | Software catalog | Yes | Yes | Yes | | Self-service workflows | Yes | Yes | Yes | | AI agent integration | External tooling | External tooling | [Northflank Skills](https://github.com/northflank/skills) | | Integrated CI/CD | No | No | Yes | | Preview environments | External integration | External integration | Native | | Managed databases | No | No | Yes | | Secrets management | External integration | External integration | Native | | Application platform | No | No | Yes | | Sandbox environments | No | No | Yes | | GPU workloads | No | No | Yes | | RBAC, SSO, audit logging | Via integrations | Partial | Native | | Self-serve BYOC | Depends on infrastructure | No | Yes | Rather than integrating a developer portal with separate CI/CD tools, deployment platforms, databases, networking, secrets management, and governance, Northflank brings these capabilities together in a single control plane. Developers and AI coding assistants can also interact with the platform through [**Northflank Skills**](https://github.com/northflank/skills), allowing tools such as Claude Code, Codex, Cursor, and Gemini CLI to provision infrastructure, create preview environments, deploy services, and manage applications using natural language. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to see how Northflank combines the developer portal and execution platform in one place. ## FAQ: Backstage vs Port ### Is Backstage better than Port? It depends on your priorities. Backstage offers greater flexibility and customization, making it a good fit for organizations with dedicated platform engineering teams. Port focuses on faster implementation and lower operational overhead through a managed SaaS platform. ### Can Port replace Backstage? For many organizations, yes. Port provides software catalogs, self-service workflows, integrations, and scorecards without requiring teams to build and maintain their own portal. Organizations that need extensive customization or TechDocs may still prefer Backstage. ### Do Backstage and Port deploy applications? No. Both are developer portals rather than deployment platforms. They provide the interface for developers, while CI/CD pipelines, Kubernetes platforms, or internal developer platforms perform the actual deployment and infrastructure provisioning. ### Do I need a separate developer portal? Not necessarily. If your platform already provides service discovery, self-service workflows, Git-based deployments, preview environments, and governance, a separate developer portal may not be required. Platforms like Northflank combine both layers into a single platform. ### Which platform is easier to maintain? Port generally requires less operational effort because it's delivered as a managed SaaS platform. Backstage provides much greater flexibility but requires ongoing engineering investment to deploy, customize, upgrade, and maintain. ## Conclusion Backstage and Port both improve the developer experience, but they solve different problems. Backstage is best suited to organizations that want complete control over their internal developer portal, while Port is designed for teams that prioritize faster adoption with less operational overhead. The developer portal is only one part of an internal developer platform. Teams still need an execution layer to build, deploy, run, and operate applications behind every self-service action. Platforms like Northflank combine both layers in a single platform, reducing operational complexity while giving developers a consistent self-service experience from source code to production. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30).

What is a sandbox environment? [2026 guide]

2026-08-04T11:45:00.000Z

A sandbox environment is one of those concepts that sounds simple until you need to implement it at scale. The core idea is consistent: give code a place to run that cannot affect anything outside its defined boundary. What varies is the implementation, and the right implementation depends heavily on what you're sandboxing and why. This article covers what a sandbox environment is, the main isolation models available in 2026, how to choose between them, the operational challenges you'll run into in production, and a recommended platform for running sandboxes at scale. ## TL;DR: Key considerations for a sandbox environment - A sandbox environment is an isolated runtime that lets you execute code, test changes, or run untrusted workloads without affecting your production systems or other users' data. - Sandboxes exist on a spectrum. At one end, you have lightweight process-level isolation for quick integration testing. At the other, you have microVM-based runtimes with hard resource limits and network restrictions, which are now the standard for safely executing AI-generated code. - The key considerations are isolation strength, cold start latency, support for both ephemeral and persistent workloads, and whether you can run sandboxes inside your own infrastructure. > Platforms like [Northflank](https://northflank.com/product/sandboxes) provide secure sandbox infrastructure with microVM and advanced runtime isolation (Firecracker, gVisor, Kata), both ephemeral and persistent execution modes, and bring-your-own-cloud support, so you can run sandboxed workloads inside your own VPC rather than a third-party managed cloud. > ## What is a sandbox environment? A sandbox environment is an isolated execution context where code runs without access to resources, data, or network segments outside its defined scope, unless you explicitly allow it. You'll encounter sandboxes across several distinct use cases: - **Development and testing:** Run feature branches against a copy of production services without touching live data. - **Security research:** Execute suspicious files or code in an isolated VM to observe behavior safely. - **Multi-tenant platforms:** Isolate each customer's workload so one tenant's code or resource usage cannot affect another's. - **AI agent execution:** Autonomous agents generate and run code dynamically. That code is untrusted by default, even if your own model wrote it. All of these share the same requirement: enforceable boundaries between what runs inside and what exists outside. ## How does a sandbox environment work? Isolation is implemented at different layers of the stack, and the layer you choose determines both your security guarantees and your operational overhead. ### Process-level isolation Containers use Linux namespaces and cgroups to enforce boundaries at the OS level. They're fast to start and cheap to run, but they share the host kernel. A kernel vulnerability can break the isolation boundary entirely. ### Advanced isolation runtimes Advanced isolation runtimes sit between containers and full VMs. Firecracker and Kata use microVM-based isolation, while gVisor takes a different approach entirely, running a userspace kernel that intercepts all syscalls before they reach the host. - **Firecracker** boots a lightweight VM using KVM with significantly lower overhead than a full VM. - **gVisor** intercepts syscalls in userspace before they reach the host kernel - **Kata Containers** run containers inside lightweight VMs with separate kernels These runtimes are the current standard for running untrusted code at scale. The isolation is strong enough to mitigate most kernel exploits, and the startup overhead is acceptable for production workloads. ### Full VM isolation Full VMs run each sandbox in a separate guest OS with its own kernel. Isolation is strongest here, but cold start times run into seconds, and memory overhead is significant. This is the right choice for malware analysis or workloads with hardware-level isolation as a compliance requirement. **Run sandboxes in your own infrastructure** If you're building on AI agents or running multi-tenant workloads, you need sandbox infrastructure that fits inside your existing stack. Northflank provides [secure sandboxes](https://northflank.com/product/sandboxes) for running untrusted code at scale, with microVM and advanced runtime isolation (Firecracker, gVisor, Kata), both ephemeral and persistent execution modes, and the option to deploy entirely inside your own VPC. [Get started with Northflank](https://northflank.com/product/sandboxes) or [schedule a demo](https://cal.com/team/northflank/northflank-demo). **Related resources:** - [How to spin up a secure code sandbox and microVM in seconds with Northflank](https://northflank.com/blog/how-to-spin-up-a-secure-code-sandbox-and-microvm-in-seconds-with-northflank-firecracker-gvisor-kata-clh) - [How to sandbox AI agents in 2026: microVMs, gVisor, and isolation strategies](https://northflank.com/blog/how-to-sandbox-ai-agents) - [What is an AI sandbox?](https://northflank.com/blog/what-is-an-ai-sandbox) ## What are the main types of sandbox environments? Choosing the right sandbox type comes down to your threat model and your tolerance for overhead. | Isolation type | Mechanism | Security boundary | Typical use case | | --- | --- | --- | --- | | Container | Linux namespaces + cgroups | Shared kernel | Dev/test, low-risk workloads | | gVisor | Userspace kernel | Userspace kernel boundary | Untrusted code, multi-tenancy | | Firecracker microVM | KVM lightweight VM | Separate kernel | AI agent execution | | Kata Containers | Container in lightweight VM | Separate kernel | Regulated workloads | | Full VM | Hypervisor | Separate kernel + hardware | Malware analysis | ## What are the limitations of a sandbox environment? Sandboxes introduce real trade-offs you need to plan for, both upfront and in production. - **Cold start latency variance:** Even microVMs have startup overhead. Quoted creation times often measure only the VM boot phase and exclude image pulls, network setup, and process initialization. Your real end-to-end time will be higher, and it will vary under load. - **Resource overhead at scale:** Each sandbox carries baseline memory and CPU costs. At high concurrency, this compounds fast. You need precise resource limits and efficient scheduling to keep costs manageable. - **Network restrictions vs. functionality:** Sandboxes work best with minimal network access, but many real workloads need outbound access to install packages or call APIs. Every allowlisted endpoint is a potential escape path. - **Persistent state complexity:** Ephemeral sandboxes are simple: destroy them after use. Persistent sandboxes that maintain state across sessions require careful management of storage volumes, network identity, and lifecycle, and zombie environments that aren't properly garbage collected will accumulate and consume compute. - **Escape risks:** No isolation model is unbreakable. Kernel vulnerabilities have been exploited to break out of containers. MicroVMs significantly raise the difficulty, but resource limits, network restrictions, and least-privilege configuration all reduce your attack surface. Hardening access through an [IAM solution](https://nordlayer.com/identity-access-management/ ) further narrows that surface. ## How Northflank implements sandbox environments [Northflank](https://northflank.com/product/sandboxes) provides secure sandboxes for running untrusted code at scale with microVM and advanced runtime isolation (Kata Containers, Firecracker, gVisor), supporting both ephemeral and persistent environments in managed cloud or your own VPC. > Northflank has been running secure sandboxes sandboxes in production since 2021 across startups, public companies, and government deployments. If you need GPUs, workers, APIs, or databases running alongside your sandboxes, they run in the same platform. > ![northflank-sandbox-page.png](https://assets.northflank.com/northflank_sandbox_page_dd9fa07375.png) Here's what Northflank provides out of the box: ### Isolation and runtime Northflank supports Firecracker, gVisor, and Kata Containers. You choose the isolation model based on your workload's security requirements, and Northflank handles the orchestration. End-to-end sandbox creation runs at 1-2 seconds, covering the full stack. ### Ephemeral and persistent environments You get both. Ephemeral sandboxes for short-lived execution and persistent environments for stateful workloads like development environments, long-running agents, or user sessions that need to survive beyond a single request. ### Bring your own cloud Most enterprise teams deploying sandboxed workloads can't accept their code or data leaving their own infrastructure. Northflank supports [bring-your-own-cloud](https://northflank.com/product/bring-your-own-cloud) deployment inside your own VPC on AWS, GCP, Azure, Oracle Cloud, CoreWeave, Civo, bare-metal, and on-premises, and it's available self-serve. ### Full workload runtime You can run APIs, background workers, databases, and AI agent infrastructure alongside your sandbox pool on the same platform. [GPU workloads](https://northflank.com/product/gpu-paas) are supported with on-demand provisioning and no quota requests. ### Access and pricing Sandboxes are accessible via API, CLI, and SSH. CPU at $0.01667/vCPU-hour, memory at $0.00833/GB-hour. Full pricing, including GPUs, is on the [Northflank pricing page](https://northflank.com/pricing). **Northflank at 100,000 concurrent sandboxes**. In the [ComputeSDK 2026 Scale Invitational](https://platform.computesdk.com/scale-invitational/northflank), Northflank reached 100,000 concurrent live sandboxes in 24 seconds from a cold start with zero failures, the fastest time of any participant. P99 allocate latency was 566ms and P99 readiness was 733ms, compared to 2.69s and 1.42s for E2B and 1.51s and 3.67s for Modal. At scale, tail latency determines the slowest sandbox your system waits on before the full fleet is live. [See the full results](https://platform.computesdk.com/scale-invitational). ![Screenshot 2026-06-23 at 09.50.13.png](https://assets.northflank.com/Screenshot_2026_06_23_at_09_50_13_f49c498ad4.png) ## What should you prioritize when choosing a sandbox environment? The right sandbox approach depends on your threat model and workload type. Work through these questions: - **Who controls the code?** If it's trusted code from your own engineers, container-level isolation is likely sufficient. If it's AI-generated or user-submitted, use microVM isolation. The overhead is worth it. - **Ephemeral or persistent?** If your use case requires session state across requests, confirm your platform supports persistent sandboxes, not just fire-and-forget execution. - **Where does the code run?** If you have data residency requirements or can't send code to a third-party cloud, BYOC deployment is a hard requirement. - **What's your scale?** At low request volume, a simple container pool works. At high concurrency with burst traffic, you need pre-warming, efficient scheduling, and per-sandbox resource enforcement. ## Frequently asked questions about sandbox environments ### What is an example of a sandbox environment? A Firecracker microVM that spins up when an AI agent needs to execute generated Python code, runs it with no outbound network access and a defined memory cap, returns the output, and is destroyed after the session. Another example: a per-developer environment that mirrors production services but has no access to production data. ### Why is it called a sandbox? The term comes from the physical concept of a sandbox: a bounded area where you can experiment freely without the mess spreading to the surrounding environment. In software, it maps to an isolated execution context where changes and side effects are contained. ### What is the difference between a sandbox and a test environment? A test environment is a deployment stage used for running automated tests before releasing to production. A sandbox is about execution isolation for safety or tenancy reasons. You can run tests inside a sandbox, but a staging environment running trusted code is not a sandbox in the security sense. ### What are the different types of sandboxes? The main types are process-isolated containers, gVisor (userspace kernel), microVMs (Firecracker, Kata), and full VMs. Each trades isolation strength for startup speed and resource overhead. MicroVMs are the current standard for untrusted code execution. ### Why are sandbox environments important for AI? AI coding assistants and autonomous agents often execute generated code before it reaches production. Sandbox environments isolate that code from the underlying infrastructure, allowing developers and AI agents to build, test, and validate changes without affecting production systems. ### Can malware escape a sandbox? Yes. Kernel vulnerabilities have been used to break out of container-based sandboxes. MicroVMs significantly raise the difficulty by providing a separate kernel, but no isolation model is unbreakable. Defense-in-depth, combining strong isolation with network restrictions, resource limits, and least-privilege config, is the right approach. ## Related articles on sandbox environments and secure code execution - [What is an AI sandbox?](https://northflank.com/blog/what-is-an-ai-sandbox) - [How to sandbox AI agents: microVMs, gVisor, and isolation strategies](https://northflank.com/blog/how-to-sandbox-ai-agents) - [Best alternatives to E2B.dev for running untrusted code in secure sandboxes](https://northflank.com/blog/best-alternatives-to-e2b-dev-for-running-untrusted-code-in-secure-sandboxes) - [Top AI sandbox platforms, ranked](https://northflank.com/blog/top-ai-sandbox-platforms-for-code-execution) - [Self-hosted AI sandboxes: guide to secure code execution](https://northflank.com/blog/self-hosted-ai-sandboxes) - [10 best CodeSandbox alternatives](https://northflank.com/blog/codesandbox-alternatives)

How to prevent AI-generated code from breaking production

2026-08-03T15:00:00.000Z

## TL;DR: How to prevent AI-generated code from breaking production - **Deploy every AI-generated pull request to its own preview environment** so changes can be tested in isolation before they're merged. - **Keep secrets out of source code** with runtime secret management, and use automated secret scanning as an additional safety net. - **Validate merged changes in staging, isolate AI-generated runtime execution with sandboxes, and make rollback instant** so failures never become long-running incidents. > Shipping AI-generated code safely requires more than CI/CD. Northflank combines [preview environments](https://northflank.com/product/preview-environments), staging, [secrets management](https://northflank.com/docs/v1/application/secure/security-on-northflank#secret-management), [sandbox isolation](https://northflank.com/product/sandboxes), rollback, [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [audit logging](https://northflank.com/docs/v1/application/observe/audit-logs), and [self-serve BYOC](https://northflank.com/product/bring-your-own-cloud) in a single platform, making it easy to deploy AI-generated applications with production-ready guardrails. [Get started (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > AI coding tools have changed how software gets built. They can generate features, refactor codebases, fix bugs, and open pull requests in minutes. The challenge isn't that AI writes bad code. It's that AI allows code to move through your delivery pipeline much faster than before. The way to prevent AI-generated code from breaking production isn't to slow AI down. It's to build deployment guardrails that automatically catch problems before they reach users. This guide covers the infrastructure controls every team should have in place when shipping AI-generated code. ## Why AI-generated code needs different deployment guardrails AI doesn't introduce a new category of software bugs. It changes how quickly code reaches production. AI coding tools can generate large pull requests across multiple files and services in minutes. Teams review more code, merge more frequently, and rely much more heavily on automation than they did before. That makes the deployment pipeline the primary safety net. Every change, whether written by a human or an AI assistant, should be validated automatically before users ever see it. The following deployment guardrails dramatically reduce the chances of AI-generated code causing production incidents. ## 1. Deploy every pull request to a preview environment The most effective way to prevent AI-generated code from breaking production is to create a preview environment for every pull request. A preview environment is a temporary, isolated copy of your application that deploys automatically whenever a pull request is opened. Instead of testing changes locally or waiting until after the merge, every AI-generated change gets its own live environment with its own services, networking, and databases. Rather than manually provisioning test environments, every pull request can be validated automatically. A production-ready preview environment should include: - The complete application stack - Isolated databases or database branches - Production-like configuration - Temporary URLs for testing - Automatic cleanup after merge Preview environments also let the AI agent validate its own changes against a live URL before a human reviews the pull request, catching many integration issues automatically. [Northflank automatically creates preview environments for every pull request](https://northflank.com/product/preview-environments), deploying complete application stacks with isolated databases, networking, and temporary URLs. Preview environments are destroyed automatically once the pull request is merged, making them practical even for teams shipping hundreds of AI-generated pull requests every week. ## 2. Keep secrets out of source code One of the most common ways AI-generated code creates security problems isn't through logic errors. It's by exposing secrets. AI coding assistants frequently work with configuration files, environment variables, and deployment manifests. If credentials appear anywhere in the agent's context, they can accidentally end up in generated code, configuration files, or commit history. Secret scanning helps detect these mistakes before code is merged, but it's only the last line of defence. The better approach is ensuring secrets never appear in source code. Applications should retrieve credentials securely at runtime from a centralized secrets manager rather than storing them in configuration files or repositories. Secret scanning then becomes a safety net rather than the primary defence. [Northflank Secret Groups](https://northflank.com/docs/v1/application/secure/security-on-northflank#secret-management) securely store credentials and inject them into workloads at build time or runtime, so API keys, database passwords, and service tokens never need to live in your repository. Combined with GitHub Advanced Security, Semgrep, or Snyk secret scanning, teams can prevent secrets from reaching production even when code is AI-generated. ## 3. Validate everything in staging before production Preview environments validate individual pull requests. Staging validates the combined application after those changes have been merged. Some problems only appear when multiple services, database migrations, and shared libraries are deployed together. A staging environment catches those issues before users do. [Northflank supports multi-stage deployment pipelines](https://northflank.com/docs/v1/application/release/ci-cd-on-northflank#release-with-environments) that automatically promote changes through preview environments, staging, and production while enforcing deployment gates, health checks, and approval workflows at each stage. ## 4. Isolate AI-generated code that executes at runtime Not every AI-generated problem comes from deployment. Some appear when AI-generated code executes in production. Coding agents, shell tools, and code interpreters should execute inside isolated sandbox environments so failures cannot affect production services or neighbouring workloads. MicroVM-based sandboxes provide stronger isolation than traditional containers by giving every execution its own lightweight virtual machine. [Northflank Sandboxes](https://northflank.com/product/sandboxes) support multiple isolation technologies, including Firecracker, Kata Containers, and gVisor, allowing AI-generated code to execute securely without exposing neighbouring services or production infrastructure. ## 5. Make rollback instant Even with strong deployment guardrails, failures still happen. The difference between a minor incident and a major outage is often how quickly you can recover. Every deployment should be reversible in seconds. A simple deployment workflow looks like this: 1. AI generates a pull request. 2. Secrets and CI checks run automatically. 3. A preview environment is deployed. 4. The change is reviewed and merged. 5. Staging validates the integrated application. 6. Production is updated. 7. If anything fails, rollback restores the previous deployment immediately. Northflank maintains deployment history for every service, making it possible to redeploy a previous release in a single click while the issue is investigated. ## How Northflank helps teams ship AI-generated code safely Preventing AI-generated code from breaking production requires more than a CI/CD pipeline. Teams also need preview environments, staging, secrets management, runtime isolation, rollback, and governance working together. Rather than assembling these capabilities across multiple tools, Northflank provides them in a single platform. Because these capabilities share the same control plane, teams don't have to integrate separate CI/CD platforms, secrets managers, preview environment tools, and sandbox providers to build a secure AI delivery pipeline. ### What is Northflank? Northflank is a cloud platform for building, deploying, and operating modern applications. Applications, AI workloads, preview environments, sandbox environments, databases, object storage, and networking all run within the same control plane. Whether you're shipping AI-generated applications, AI coding agents, or traditional software, Northflank provides the infrastructure needed to move changes safely from pull request to production. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > **Need to deploy inside your own cloud?** [Northflank BYOC](https://northflank.com/product/bring-your-own-cloud) lets you deploy the entire platform into your own AWS, Azure, GCP, Oracle, CoreWeave, or on-premises infrastructure while using the same workflows, API, and developer experience. > From the moment an AI agent opens a pull request, Northflank provides the deployment guardrails that help prevent production incidents. ### What Northflank provides - [**Preview environments**](https://northflank.com/product/preview-environments) automatically create isolated environments for every pull request, complete with services, databases, networking, and temporary URLs for validation. - [**Integrated CI/CD pipelines**](https://northflank.com/docs/v1/application/release/ci-cd-on-northflank) promote changes through preview environments, staging, and production with deployment gates, health checks, and approval workflows. - [**Secrets management**](https://northflank.com/docs/v1/application/secure/security-on-northflank#secret-management) keeps credentials out of source code by injecting them securely at build time and runtime through Secret Groups. - [**Sandbox environments**](https://northflank.com/product/sandboxes) use Firecracker, Kata Containers, and gVisor to isolate AI-generated code that executes at runtime. - **Rollback and deployment history** allow teams to restore previous deployments in seconds if a release introduces problems. - [**RBAC**](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [**SSO**](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication), and [**audit logging**](https://northflank.com/docs/v1/application/observe/audit-logs) provide enterprise governance across projects, environments, and deployments. - [**Built-in networking and service discovery**](https://northflank.com/docs/v1/application/network/networking-on-northflank) allow applications to communicate securely without exposing unnecessary services. - [**BYOC**](https://northflank.com/product/bring-your-own-cloud) and [**forward-deployed control planes**](https://northflank.com/enterprise) deploy the same platform into your own cloud account when workloads must remain inside your own infrastructure. - [**Northflank Skills**](https://github.com/northflank/skills) for Claude Code, Codex, Cursor, Gemini CLI, and other AI coding assistants allow AI agents to provision preview environments, configure deployments, and manage infrastructure directly through natural language. Northflank has also demonstrated the scale required for AI-native software delivery. In the [ComputeSDK 2026 Scale Invitational](https://platform.computesdk.com/scale-invitational/northflank), Northflank launched **100,000 concurrent sandbox environments in just 24 seconds** from a cold start with **zero failures**, showing that AI workloads can scale rapidly without sacrificing startup performance or isolation. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to see how Northflank helps teams ship AI-generated code safely. ## FAQ: Preventing AI-generated code from breaking production ### What's the biggest risk when shipping AI-generated code? Usually not incorrect syntax. The biggest risks are integration failures, leaked secrets, configuration mistakes, and runtime behaviour that isn't discovered until after deployment. Deployment guardrails such as preview environments, staging, and rollback catch these problems before they affect users. ### Are preview environments really necessary for AI-generated code? Yes. AI coding tools generate changes much faster than humans, making manual testing impractical. Preview environments give every pull request its own isolated application stack so changes can be validated before merging. ### Is secret scanning enough? No. Secret scanning should be treated as a safety net, not the primary defence. The better approach is storing credentials in a secrets manager and injecting them at runtime so secrets never appear in source code. ### Why should AI-generated code run inside sandboxes? Some AI-generated code executes dynamically through coding agents, shell commands, or code interpreters. Running those executions inside isolated sandbox environments prevents a failure or compromise from affecting production services or neighbouring workloads. ### What's the difference between preview environments and staging? Preview environments validate individual pull requests before they're merged. Staging validates the combined application after multiple changes have been merged but before they're deployed to production. Both are essential because they catch different classes of problems. ### Can AI-generated applications be deployed inside our own cloud? Yes. Platforms that support Bring Your Own Cloud (BYOC), such as Northflank, let teams deploy the entire delivery pipeline into their own AWS, Azure, GCP, Oracle, CoreWeave, or on-premises environment while keeping the same deployment workflows and governance controls. # Conclusion AI-generated code doesn't need a different deployment process. It needs stronger deployment guardrails. Preview environments, secrets management, staging, sandbox isolation, and rollback let teams move quickly without increasing production risk. Northflank brings these guardrails together in one platform, making it easier to ship AI-generated applications safely, whether you're deploying traditional software, AI-powered applications, or autonomous coding agents. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ## Related articles - [**Best enterprise AI sandbox platforms**](https://northflank.com/blog/best-enterprise-ai-sandbox-platforms) - [**How to secure AI agents in the cloud**](https://northflank.com/blog/how-to-secure-ai-agents-in-the-cloud) - [**What is a sandbox?**](https://northflank.com/blog/what-is-a-sandbox-and-isolation-technologies) - [**How to set up CI/CD for a vibe-coded app**](https://northflank.com/blog/how-to-set-up-ci-cd-for-a-vibe-coded-app)

CI/CD for AI-generated code: what changes and what stays the same

2026-08-03T15:00:00.000Z

## TL;DR: CI/CD for AI-generated code - **The fundamentals of CI/CD don't change.** AI-generated code still needs to be built, tested, validated, staged, and deployed before reaching production. - **AI increases the speed and volume of software delivery**, making preview environments, automated testing, staging, rollback, and secrets management more important than ever. - [**Northflank**](https://northflank.com/) provides an AI-ready CI/CD platform** with preview environments, integrated CI/CD, staging, rollback, secrets management, [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [audit logging](https://northflank.com/docs/v1/application/observe/audit-logs), sandbox environments, and self-serve BYOC in a single platform. > Shipping AI-generated code safely requires more than a build pipeline. Northflank combines [preview environments](https://northflank.com/product/preview-environments), staging, [secrets management](https://northflank.com/docs/v1/application/secure/security-on-northflank#secret-management), [deployment workflows](https://northflank.com/product/deployments), rollback, [sandbox environments](https://northflank.com/product/sandboxes), and enterprise governance in one platform, making it easy to ship AI-generated applications with confidence. [Get started (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > AI coding tools haven't replaced CI/CD. They've changed how quickly code moves through it. AI can generate features, fix bugs, and open pull requests in minutes, allowing teams to ship far more code than before. The core principles of CI/CD remain the same. You still build, test, validate, stage, and deploy. What's changed is that every stage now needs to be more automated, scalable, and reliable to keep pace with AI-assisted development. 💡 **Want to build this pipeline?** This guide focuses on what changes when code is AI-generated. For a practical walkthrough, see [**How to set up CI/CD for a vibe-coded app**](https://northflank.com/blog/how-to-set-up-ci-cd-for-a-vibe-coded-app), where you'll learn how to build a production-ready CI/CD pipeline with preview environments, staging, secrets management, rollback, and automated deployments. ## What stays the same? AI coding assistants haven't changed the fundamentals of CI/CD. Every change, whether written by a human or generated by AI, should still be built, tested, validated, staged, and deployed before reaching production. Git, pull requests, automated testing, deployment pipelines, and rollback remain essential. What changes isn't the pipeline. It's how quickly code moves through it. ## What changes? The pipeline itself doesn't change. The workload placed on it does. AI-generated code increases the speed and volume of software delivery, making automation more important than ever. - **More pull requests:** Every validation step needs to run automatically. - **Larger changes:** AI often modifies multiple services and configuration files at once, increasing integration risk. - **Faster feedback:** AI agents can read pipeline failures, generate fixes, and resubmit changes automatically. ## What an AI-ready CI/CD pipeline looks like The stages stay the same. The level of automation and validation increases. ### 1. Pull request validation Every AI-generated pull request should automatically trigger the same baseline validation as human-written code. This includes: - Linting and formatting - Dependency vulnerability scanning - Static application security testing (SAST) - Secret scanning Because AI generates code at much higher volume, these checks should be mandatory and fully automated. The goal isn't to slow development down. It's to catch obvious failures before reviewers spend time on them. ### 2. Preview environments become essential Preview environments are no longer optional. With AI-generated code, they're one of the most important deployment guardrails. Every pull request should automatically deploy its own isolated copy of the application, including dependent services, networking, and production-like configuration. This allows reviewers and even the AI agent itself to validate changes before anything is merged. A production-ready preview environment should include: - The complete application stack - Production-like configuration - Isolated databases or database branches - Temporary URLs for testing - Automatic cleanup after merge [Northflank](https://northflank.com/product/preview-environments) automatically creates preview environments for every pull request, making it practical to validate hundreds of AI-generated changes every week without manual infrastructure management. ### 3. Testing becomes more important AI doesn't eliminate testing. It increases its importance. Beyond unit tests, AI-generated changes should also pass: - Integration tests - End-to-end tests - Smoke tests - Health checks Because AI often modifies multiple services in a single change, integration testing becomes even more important. Many failures only appear once the complete application is running. ### 4. Staging remains the final checkpoint Preview environments validate individual pull requests. Staging validates the combined application. Multiple AI-generated pull requests may work perfectly on their own but fail once deployed together. That's why staging should mirror production as closely as possible and become the final approval gate before deployment. A good staging environment should: - Deploy through the same pipeline as production - Mirror production infrastructure - Run automated smoke tests - Require health checks before promotion [Northflank](https://northflank.com/docs/v1/application/release/ci-cd-on-northflank#release-with-environments) supports deployment pipelines that automatically promote workloads through preview environments, staging, and production while enforcing deployment gates throughout the process. ### 5. Rollback needs to be instant No deployment pipeline prevents every production incident. Recovery speed matters just as much as prevention. Every deployment should create a version that can be restored immediately if something goes wrong. For AI-generated code, this is even more important because changes often span multiple services and may be difficult to diagnose immediately. The safest workflow is simple: 1. Roll back production. 2. Restore service. 3. Investigate. 4. Generate a fix. Northflank maintains deployment history for every service, allowing teams to restore previous deployments in seconds. ## What's new in AI-native CI/CD? One capability didn't exist before AI coding assistants. The pipeline can now become part of the AI agent's feedback loop. When a build fails, an AI agent can: - Read compiler errors - Understand test failures - Fix lint violations - Update the pull request - Trigger another pipeline run Instead of simply rejecting changes, the CI/CD pipeline becomes a continuous feedback loop that helps improve code before a human reviewer becomes involved. [Northflank Skills](https://github.com/northflank/skills) extend this even further, allowing Claude Code, Codex, Cursor, Gemini CLI, and other AI assistants to interact directly with deployment infrastructure through natural language. ## What AI doesn't replace AI doesn't remove the need for CI/CD. If anything, it makes CI/CD more important. As AI accelerates software delivery, automated validation, preview environments, staged deployments, and rollback become the mechanisms that allow teams to ship faster without increasing production risk. ## How Northflank provides AI-ready CI/CD Shipping AI-generated applications safely requires more than a CI/CD pipeline. Teams also need preview environments, staging, deployment approvals, secrets management, rollback, runtime isolation, networking, observability, and governance. As AI coding assistants generate more pull requests and ship code faster, stitching those capabilities together across multiple tools quickly becomes operational overhead. Northflank brings those capabilities together in a single platform. Applications, preview environments, deployment pipelines, sandbox environments, databases, object storage, networking, and AI workloads all run within the same control plane, making it easier to move changes from pull request to production without managing separate infrastructure. ### What is Northflank? Northflank is a cloud platform for building, deploying, and operating modern applications. Whether you're shipping AI-generated applications or traditional software, Northflank provides the infrastructure needed to move changes safely from pull request to production. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > **Need to deploy inside your own cloud?** [Northflank BYOC](https://northflank.com/product/bring-your-own-cloud) lets teams deploy the same platform into AWS, Azure, GCP, Oracle, CoreWeave, or on-premises infrastructure while keeping the same workflows, APIs, and developer experience. > From the moment an AI coding agent opens a pull request, Northflank provides the deployment guardrails that help keep production stable. Whether code is generated by Claude Code, Codex, Cursor, Gemini CLI, or another AI coding tool, the deployment workflow remains the same. ### What Northflank provides - [**Integrated CI/CD pipelines**](https://northflank.com/docs/v1/application/release/ci-cd-on-northflank) build and deploy applications directly from Git with automated workflows, environment promotion, and support for any language or framework. - [**Preview environments**](https://northflank.com/product/preview-environments) automatically create isolated application stacks for every pull request, complete with services, databases, networking, and temporary URLs for validation. - [**Secrets management**](https://northflank.com/docs/v1/application/secure/security-on-northflank#secret-management) keeps credentials out of source code by securely injecting them at build time and runtime through Secret Groups. - **Staging environments and release flows** enforce deployment gates, health checks, approvals, and controlled promotion before production. - **Rollback and deployment history** allow teams to restore previous deployments in seconds if a release introduces problems. - [**Sandbox environments**](https://northflank.com/product/sandboxes) use Firecracker, Kata Containers, and gVisor to safely execute AI-generated code at runtime with stronger isolation than containers. - [**RBAC**](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [**SSO**](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication), and [**audit logging**](https://northflank.com/docs/v1/application/observe/audit-logs) provide enterprise governance across users, projects, environments, and deployments. - [**Built-in networking and service discovery**](https://northflank.com/docs/v1/application/network/networking-on-northflank) allow applications and services to communicate securely without unnecessary exposure. - [**BYOC**](https://northflank.com/product/bring-your-own-cloud) and [**forward-deployed control planes**](https://northflank.com/enterprise) deploy the same platform into your own AWS, Azure, GCP, Oracle, CoreWeave, or on-premises infrastructure when workloads must remain inside your own environment. - [**Northflank Skills**](https://github.com/northflank/skills) for Claude Code, Codex, Cursor, Gemini CLI, and other AI coding assistants allow them to provision infrastructure, configure deployments, create preview environments, and manage applications using natural language. Because every part of the deployment workflow runs on the same platform, teams don't need separate tools for CI/CD, preview environments, staging, secrets management, rollback, runtime isolation, and governance. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to see how Northflank helps teams build AI-ready CI/CD pipelines. ## FAQ: CI/CD for AI-generated code ### Is CI/CD different for AI-generated code? The core pipeline is the same. AI-generated code still needs to be built, tested, validated, staged, and deployed. The difference is that automation becomes much more important because AI dramatically increases delivery speed. ### Why are preview environments important for AI-generated code? They allow every pull request to run inside its own isolated application stack, making it easier to catch integration issues before changes are merged. ### Can AI agents fix failing CI/CD pipelines? Yes. Modern AI coding assistants can read build logs, understand test failures, generate fixes, and update pull requests automatically, turning CI/CD into a continuous feedback loop. ### Do AI-generated applications still need staging? Absolutely. Preview environments validate individual pull requests, while staging validates the combined application before production. ### Can AI-generated applications use BYOC? Yes. Platforms like Northflank support self-serve Bring Your Own Cloud (BYOC), allowing teams to deploy the entire CI/CD pipeline inside their own cloud account while maintaining the same workflows and governance controls. ## Conclusion The fundamentals of CI/CD haven't changed. AI-generated code still needs to be built, tested, validated, staged, and deployed before it reaches production. As AI coding assistants continue to accelerate software delivery, the quality of your CI/CD pipeline becomes even more important. Platforms like [Northflank](https://northflank.com/) combine preview environments, deployment workflows, staging, rollback, secrets management, and governance in a single platform, helping teams ship AI-generated applications quickly without sacrificing reliability or security. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ## Related articles - [**How to set up CI/CD for a vibe-coded app**](https://northflank.com/blog/how-to-set-up-ci-cd-for-a-vibe-coded-app): Step-by-step guide to building a production-ready CI/CD pipeline for AI-built applications. - [**How to auto-create preview environments on every PR**](https://northflank.com/blog/how-to-auto-create-preview-environments-on-every-pr): Automatically deploy isolated preview environments for every pull request. - [**Top AI tools for CI/CD pipeline automation**](https://northflank.com/blog/top-ai-tools-cicd-pipeline-automation): Compare AI-powered tools for automating software delivery and deployment workflows. - [**How to prevent AI-generated code from breaking production**](https://northflank.com/blog/how-to-prevent-ai-generated-code-from-breaking-production): Deployment guardrails that reduce production incidents when shipping AI-generated code.

Best GPUs for running open-source and open-weight AI models in 2026

2026-07-31T17:14:00.000Z

The best GPU for an open-weight model is not always the accelerator with the highest specifications. It is the GPU with enough memory for your model, context, and batch size, support for your software stack, and sustainable performance at the right cost. This article compares six GPUs for local inference, workstation development, fine-tuning, and production serving. ## TL;DR: Best GPUs for open-source and open-weight AI models - **Best consumer GPU for local NVIDIA inference:** NVIDIA GeForce RTX 5090. - **Best AMD GPU for local inference:** AMD Radeon RX 7900 XTX, if your ROCm environment is supported. - **Best workstation GPU for large models:** NVIDIA RTX PRO 6000 Blackwell. - **Best economical production GPU:** NVIDIA L4 for smaller inference workloads. - **Best options in this comparison for larger production workloads:** NVIDIA H100 for high-throughput workloads that fit within 80 GB, and NVIDIA H200 when memory capacity, memory bandwidth, long contexts, or KV-cache size becomes the constraint. Production inference needs more than GPU compute. On Northflank, you can deploy open-weight models alongside APIs, workers, jobs, databases, storage, CI/CD, autoscaling, secrets, and observability in one workflow, either on [Northflank Cloud](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-on-northflank-cloud) or through [self-serve BYOC](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud) in your own AWS, GCP, or Azure account. Startups can move from model testing to production without first building an internal platform. Enterprise teams can keep infrastructure, networking, IAM, data residency, and cloud billing in their own account while using Northflank for deployment, scaling, and application operations. [Request GPU capacity](https://northflank.com/request/gpu), [get started self-serve](https://app.northflank.com/), or [talk to a Northflank engineer](https://cal.com/team/northflank/northflank-demo?duration=30) about architecture, security, compliance, data residency, or migration requirements. ## What makes a GPU the best choice for an open-weight model? Start with the workload. Local experimentation, parameter-efficient fine-tuning, a low-traffic API, and a high-concurrency production service require different hardware. Compare these factors: - **GPU memory:** Weights, KV cache, runtime overhead, activations, context, and batching consume memory. - **Memory bandwidth:** Higher bandwidth can improve inference when moving model weights becomes the bottleneck. - **Software support:** Check the runtime, quantization method, driver, operating system, and GPU architecture together. - **Deployment model:** Consumer, workstation, and data-center GPUs solve different operational problems. - **Total cost:** Include CPU, RAM, storage, networking, power, cooling, utilization, and engineering overhead. ## How much GPU memory does an open-weight model need? Use `parameter count × bits per weight ÷ 8` for a theoretical weights-only estimate. | Model size | 4-bit weights | 8-bit weights | FP16 or BF16 weights | | --- | --- | --- | --- | | 8B | 4 GB | 8 GB | 16 GB | | 32B | 16 GB | 32 GB | 64 GB | | 70B | 35 GB | 70 GB | 140 GB | These are planning floors, not complete VRAM requirements. Quantized formats also store scales, zero points, metadata, and sometimes padding, so the weights can consume slightly more memory than the simple calculation suggests. You still need space for the KV cache, temporary buffers, runtime overhead, context, and concurrent sequences. Fine-tuning requires additional memory. Quantization can reduce memory use. Hugging Face Transformers supports 8-bit and 4-bit loading through bitsandbytes, while llama.cpp supports several quantization levels and NVIDIA CUDA, AMD HIP, Apple Metal, and other backends. ## Best GPUs for open-source and open-weight models compared Consumer prices exclude the host system, while cloud rates can include different CPU, RAM, storage, and network resources. | GPU | Best for | Memory | Bandwidth or interface | Price reference | | --- | --- | --- | --- | --- | | NVIDIA GeForce RTX 5090 | Local CUDA inference | 32 GB GDDR7 | 512-bit interface | Starts at $1,999 | | AMD Radeon RX 7900 XTX | AMD-first local builds | 24 GB GDDR6 | Up to 960 GB/s | Launch SEP: $999 | | NVIDIA RTX PRO 6000 Blackwell | Large-model workstations | 96 GB GDDR7 ECC | 1.8 TB/s | Northflank: $3.00/hour | | NVIDIA L4 | Cost-conscious inference | 24 GB | 300 GB/s | Northflank: $0.80/hour | | NVIDIA H100 SXM | High-throughput production | 80 GB HBM3 | 3.35 TB/s | Northflank: $2.74/hour | | NVIDIA H200 | Memory-heavy inference | 141 GB HBM3e | 4.8 TB/s | Northflank: $3.14/hour | | NVIDIA A100 | Cost-conscious CUDA workloads | 40 GB HBM2 or 80 GB HBM2e | Up to 2,039 GB/s | Northflank: $1.42/hour (40 GB) or $1.76/hour (80 GB) | | NVIDIA B200 | Large-scale training and clustered inference | 180 GB HBM3e | HGX configuration | Northflank: $5.87/hour | ## What are the best GPUs for running open-source and open-weight models? The six GPUs below cover local development, large-model workstations, cost-conscious inference, and high-throughput production deployments. ### 1. NVIDIA GeForce RTX 5090 The NVIDIA GeForce RTX 5090 is a Blackwell-generation consumer desktop GPU with 32 GB GDDR7. It is the strongest option in this list for local developers who want CUDA without moving to workstation or data-center hardware. - **Best for:** Local inference, model testing, and quantized models that need more than 24 GB. - **Key specifications:** 32 GB GDDR7, a 512-bit memory interface, and a starting price of $1,999. Retail prices vary. - **Main trade-off:** It remains a desktop GPU without production scheduling, shared access, deployment workflows, or service observability. **Moving from local development to production:** When your model becomes a production service, you can [deploy GPU-backed services and jobs on Northflank](https://northflank.com/docs/v1/application/gpu-workloads/gpus-on-northflank) with the surrounding application stack. ### 2. AMD Radeon RX 7900 XTX The AMD Radeon RX 7900 XTX is an RDNA 3 consumer desktop GPU with 24 GB GDDR6. It is the main AMD option here for local inference when your runtime supports ROCm or HIP. - **Best for:** AMD-first local builds and developers using llama.cpp through HIP. - **Key specifications:** 24 GB GDDR6, up to 960 GB/s bandwidth, and 355 W typical board power. Its $999 figure is the launch price, not a current street price. - **Main trade-off:** Compatibility depends on the exact GPU, ROCm release, operating system, driver, and framework. Check the complete AMD support matrix before buying. **Taking an AMD workload into production:** GPU availability and software support depend on the cloud provider, region, and node type. With [Northflank BYOC](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud), you can deploy supported GPU node pools in your cloud account while keeping the application workflow consistent. ### 3. NVIDIA RTX PRO 6000 Blackwell The NVIDIA RTX PRO 6000 Blackwell is a professional workstation GPU with 96 GB GDDR7 ECC. It bridges the gap between consumer cards and data-center accelerators for teams that want large memory in one workstation. - **Best for:** Quantized 70B-class models, longer contexts, larger batches, and selected local fine-tuning workflows. - **Key specifications:** 96 GB GDDR7 ECC, 1.8 TB/s bandwidth, PCIe Gen 5, MIG support, and a 600 W power design. - **Main trade-off:** Its 600 W power design requires suitable workstation power, cooling, and physical space. **Use workstation-class memory without buying the hardware:** You can run an [NVIDIA RTX PRO 6000 96 GB GPU instance on Northflank](https://northflank.com/cloud/gpus) for $3.00 per hour and deploy the model alongside APIs, jobs, databases, and other application services. ### 4. NVIDIA L4 The NVIDIA L4 is a low-profile Ada Lovelace data-center GPU built for inference, video, and graphics workloads. Its 24 GB memory and low power profile make it a practical production step up from local hardware. - **Best for:** Smaller quantized LLMs, embeddings, rerankers, image generation, and video inference. - **Key specifications:** 24 GB memory, 300 GB/s bandwidth, 72 W maximum TDP, and a single-slot server form factor. - **Main trade-off:** Models, contexts, or batches that exceed 24 GB need a larger accelerator or offloading. **Deploy an L4-backed application:** On Northflank, you can run an L4 for $0.80 per hour as a service or job and connect it to APIs, workers, databases, CI/CD, autoscaling, and observability. See the [NVIDIA L4 cost guide](https://northflank.com/blog/how-much-does-an-nvidia-l4-gpu-cost) for configurations and deployment options. ### 5. NVIDIA A100 The NVIDIA A100 is an Ampere data-center accelerator available with 40 GB or 80 GB of high-bandwidth memory. It remains a practical option for established CUDA workloads that need more memory and data-center features than the L4 without moving to H100 pricing. - **Best for:** Cost-conscious production inference, fine-tuning, and training workloads that already run well on CUDA and do not require Hopper FP8 support or the Transformer Engine. - **Key specifications:** The A100 40 GB provides 40 GB HBM2 and up to 1,555 GB/s memory bandwidth. The A100 80 GB provides 80 GB HBM2e and up to 1,935 GB/s on PCIe or 2,039 GB/s on SXM. Both support MIG. - **Main trade-off:** The A100 uses the older Ampere architecture and offers less memory bandwidth and lower transformer throughput than newer H100 and H200 accelerators. **Run established CUDA workloads at a lower hourly price:** On Northflank, you can run an NVIDIA A100 40 GB for $1.42 per hour or an A100 80 GB for $1.76 per hour. This suits startups and engineering teams that need data-center GPU memory without paying for H100-class capacity. See the [NVIDIA A100 cost guide](https://northflank.com/blog/nvidia-a100-gpu-cost) for more detail. ### 6. NVIDIA H100 The NVIDIA H100 is a Hopper data-center accelerator designed for high-throughput AI training and inference. It becomes relevant when concurrency, batching, fine-tuning, or multi-GPU operation outweighs the cost advantage of smaller GPUs. - **Best for:** High-throughput production inference, larger models, fine-tuning, and multi-GPU systems. - **Key specifications:** H100 SXM provides 80 GB HBM3, 3.35 TB/s bandwidth, MIG support, and 900 GB/s NVLink. - **Main trade-off:** H100 SXM and H100 NVL have different memory, power, and interconnect specifications, so confirm the exact variant. **Run H100 workloads with the surrounding platform:** You can run an NVIDIA H100 80 GB on Northflank for $2.74 per hour. Startups can use managed infrastructure, while enterprises can use BYOC to keep workloads, networking, IAM, regional placement, and billing in their cloud account. See the [NVIDIA H100 cost guide](https://northflank.com/blog/how-much-does-an-nvidia-h100-gpu-cost) for more detail. ### 7. NVIDIA H200 The NVIDIA H200 is a Hopper data-center accelerator that increases memory capacity and bandwidth with HBM3e. It is the strongest single-GPU option in this comparison when model weights, context, KV cache, or batch size creates the bottleneck. - **Best for:** Memory-heavy inference, long contexts, large batches, and reducing model parallelism. - **Key specifications:** 141 GB HBM3e and 4.8 TB/s memory bandwidth. - **Main trade-off:** It is not automatically the most economical option. Benchmark prompt lengths, output lengths, batch sizes, concurrency, and total workload cost before choosing it over an L4, RTX PRO 6000, or H100. **Deploy memory-heavy inference on H200:** You can run an NVIDIA H200 141 GB on Northflank for $3.14 per hour. For multi-GPU, volume, or reservation requirements, [request GPU capacity](https://northflank.com/request/gpu) to confirm the right region and deployment model for your workload. ### 8. NVIDIA B200 The NVIDIA B200 is a Blackwell data-center accelerator for large-scale AI training and inference. Its 180 GB HBM3e capacity provides more memory per GPU than the H100 or H200, making it relevant when model size, runtime state, or cluster throughput exceeds what Hopper-generation GPUs can provide. - **Best for:** Very large models, high-throughput clustered inference, large-scale training, and Blackwell-optimized workloads. - **Key specifications:** 180 GB HBM3e per GPU in current NVIDIA HGX B200 configurations. - **Main trade-off:** The B200 has a higher hourly cost and may require a multi-GPU or HGX-class architecture to justify its capacity. Smaller models can be more economical on an L4, A100, H100, or H200. **Deploy Blackwell GPU workloads on Northflank:** You can run an NVIDIA B200 180 GB on Northflank for $5.87 per hour. For multi-GPU clusters, reserved capacity, or enterprise deployment requirements, [request GPU capacity](https://northflank.com/request/gpu). See the [NVIDIA B200 cost guide](https://northflank.com/blog/how-much-does-an-nvidia-b200-gpu-cost) for pricing and deployment considerations. ## When should you move beyond one GPU? Use multiple GPUs when one accelerator cannot hold the model weights and runtime state or when a single GPU cannot meet your throughput or latency target. At that point, tensor parallelism, interconnect bandwidth, node design, workload scheduling, and orchestration become part of the decision. Current NVIDIA HGX B200 and B300 configurations are designed for this type of scale. The B300 increases memory capacity to 288 GB HBM3e per GPU for workloads that exceed the capacity of a B200 or require higher-density clustered infrastructure. With [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud), your platform team can operate supported GPU node pools in your cloud account, subject to provider and regional availability. You retain control over infrastructure, networking, IAM, data residency, and existing cloud purchasing relationships. ## How should you choose the right GPU for your model? 1. Choose the exact model, runtime, precision, and quantization. 2. Estimate weights-only memory, then add headroom for context, KV cache, concurrency, and runtime overhead. 3. Validate the GPU architecture, driver, framework, operating system, and quantization library together. 4. Benchmark representative prompts, outputs, batching, latency, concurrency, and failure behaviour. 5. Compare total ownership or deployment cost rather than one GPU price. 6. Decide whether local hardware, managed cloud, BYOC, or a multi-GPU cluster fits the operating model. Consumer GPUs often suit individual engineers. Renting helps startups test changing models and traffic before purchasing hardware. BYOC helps enterprises retain infrastructure control and use committed cloud spend. Once you know the model, GPU, and deployment path, [request GPU capacity](https://northflank.com/request/gpu) for production, volume, or reservation requirements. ## How can you deploy open-weight models on Northflank? Your production system may need APIs, workers, jobs, databases, storage, private networking, secrets, CI/CD, scaling, logs, and metrics around the model. On Northflank, you can manage these components in one application workflow on [Northflank Cloud](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-on-northflank-cloud) or through [self-serve BYOC](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud) in your own infrastructure. You can choose from NVIDIA L4, A100, H100, RTX PRO 6000, H200, and B200 GPUs according to the model’s memory, throughput, and scaling requirements. - **For engineers:** Deploy GPU services and jobs from source or container images with built-in delivery and observability workflows. - **For startups:** Start with self-serve Northflank Cloud or BYOC instead of assembling a separate platform around inference. - **For enterprises:** Use Northflank BYOC to retain infrastructure, networking, IAM, data residency, cloud billing, RBAC, SSO, audit logs, and secrets controls. See [Northflank for Enterprise](https://northflank.com/enterprise) With Northflank BYOC, you can enable time-slicing on supported GPU node pools. Use the [GPU optimisation guide](https://northflank.com/docs/v1/application/gpu-workloads/configure-and-optimise-workloads-for-gpus) to prepare compatible images, right-size resources, and persist model data. **See how this operating model works at production scale:** The two-engineer team at Weights used Northflank to operate an AI platform serving millions across nine clusters, more than 40 microservices, and more than 250 concurrent GPUs without a dedicated DevOps team. Read the [Weights case study](https://northflank.com/blog/weights-uses-northflank-to-scale-to-millions-of-users-without-a-devops-team-ai-k8s), [request GPU capacity](https://northflank.com/request/gpu), [get started self-serve](https://app.northflank.com/), or [talk to an engineer](https://cal.com/team/northflank/northflank-demo?duration=30) about architecture, security, compliance, data residency, or migration. ## Frequently asked questions about GPUs for open-source and open-weight models ### How much VRAM do I need for a 7B or 8B model? An 8B model has about 4 GB of 4-bit weights, 8 GB at 8-bit, or 16 GB at FP16 or BF16. Add memory for the KV cache, runtime, context, batching, and temporary buffers. ### Can a 24 GB GPU run a 32B model? A 32B model has about 16 GB of 4-bit weights, so some quantized implementations fit. Actual capacity and context depend on the model, quantization, runtime overhead, KV cache, and batch size. ### What GPU do I need for a 70B model? A 70B model has about 35 GB of theoretical 4-bit weight storage before quantization metadata, KV cache, runtime overhead, and concurrent sequences. For many 4-bit 70B deployments, a 48 GB-class GPU is a practical starting point for experimentation, but achievable context and concurrency depend heavily on the quantization format and runtime. Production workloads can justify 80 GB, 96 GB, 141 GB, 180 GB, or multiple GPUs. ### Is it cheaper to buy or rent a GPU? Buying can suit stable workloads with high utilization. Renting can suit experiments, changing models, variable traffic, and teams that need different GPU classes. Include host hardware, power, cooling, storage, networking, maintenance, and engineering time. ## Related articles to open-source and open-weight model infrastructure - [GPU workloads on Northflank](https://northflank.com/gpu) - [Best NVIDIA L4 GPU cloud providers](https://northflank.com/blog/best-nvidia-l4-gpu-cloud-providers) - [How much does an NVIDIA A100 GPU cost?](https://northflank.com/blog/nvidia-a100-gpu-cost) - [How much does an NVIDIA H100 GPU cost?](https://northflank.com/blog/how-much-does-an-nvidia-h100-gpu-cost) - [How much does an NVIDIA B200 GPU cost?](https://northflank.com/blog/how-much-does-an-nvidia-b200-gpu-cost)

Best NVIDIA H100 cloud providers for AI inference in 2026

2026-07-31T17:11:00.000Z

Renting NVIDIA H100 capacity is only one part of running production AI training and inference. This article compares application platforms, specialist GPU infrastructure, hyperscalers, and serverless execution across pricing, topology, infrastructure control, scaling, and production workload fit. ## TL;DR: Best NVIDIA H100 GPU cloud providers - **Northflank** suits engineers, startups, and enterprises deploying H100 workloads alongside APIs, workers, jobs, databases, CI/CD, autoscaling, and observability on managed infrastructure or through self-serve BYOC. - **Runpod** suits teams that want flexible access to H100 PCIe, SXM, and NVL GPUs through Pods, Serverless, and Clusters. - **Lambda** suits teams that want dedicated H100 infrastructure with straightforward instances, reserved capacity, and a path to large AI clusters. - **CoreWeave** suits large-scale enterprise training on full NVIDIA HGX H100 nodes with specialist distributed infrastructure. - **Google Cloud and Amazon EC2** suit organizations keeping H100 workloads within an existing hyperscaler ecosystem, while **Modal** suits Python-native serverless inference and batch processing. Production H100 applications need more than GPU capacity. They also need APIs, workers, databases, storage, CI/CD, private networking, autoscaling, secrets, logs, and governance. Northflank runs these components with H100 services and jobs on one platform, using [Northflank Cloud](https://northflank.com/cloud/northflank), [self-serve BYOC](https://northflank.com/cloud/gpus) in your AWS, Azure, Google Cloud, Oracle, Civo, or CoreWeave account, or your existing on-premises and bare-metal Kubernetes infrastructure via BYOK. Enterprises can retain control over networking, IAM, regional placement, data residency, and cloud billing while using SSO, RBAC, audit logs, and standardized deployment workflows. Startups and smaller engineering teams can use the same deployment model without building and operating their own Kubernetes platform. [Request NVIDIA H100 GPU capacity](https://northflank.com/request/gpu), [get started self-serve](https://app.northflank.com/signup), or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) for architecture, security, compliance, or migration requirements. ## What to look for in an NVIDIA H100 cloud provider The accelerator may have the same name, but the hardware configuration and platform around it can produce a very different operational result. - **Workload and hardware fit:** Match PCIe, SXM, or NVL configurations and single- or multi-GPU nodes to inference, batch jobs, or distributed training. - **Access and total cost:** Compare on-demand, spot, reserved, and sales-assisted capacity, including CPU, memory, storage, transfer, idle time, and interruption risk. - **Operating model:** Decide whether you need direct infrastructure, serverless execution, or a platform that also manages deployment, scaling, observability, databases, and security controls. No single infrastructure or platform model is the right choice for every H100 deployment. The useful comparison is which provider fits the way your team builds and operates its workload. ## Is the NVIDIA H100 the right GPU for your workload? The NVIDIA H100 is a Hopper architecture data-center GPU for large-model training, high-throughput inference, and high-performance computing (HPC). The right accelerator depends on model memory, precision, batch size, communication between GPUs, software support, and total job time. H200 or Blackwell GPUs may fit workloads needing more memory or newer hardware, while smaller inference services may cost less on an L4 or A100. For specifications, purchase costs, and rental considerations, read [How much does an NVIDIA H100 GPU cost?](https://northflank.com/blog/how-much-does-an-nvidia-h100-gpu-cost). ## **NVIDIA H100 cloud providers compared** The table summarizes the differences that determine which platform fits a workload. Prices are as at 30 July 2026. | Platform | Best for | Deployment | H100 GPU pricing | Pricing scope | | --- | --- | --- | --- | --- | | Northflank | Running complete H100 applications with GPU and application infrastructure together | Managed cloud, self-serve BYOC, or existing Kubernetes via BYOK | H100 80 GB: $2.74/GPU-hour; A100, H200, B200, and more available | GPU rate includes attached CPU and RAM; billed per second | | Runpod | Renting H100s with a choice of form factors and consumption models | Pods, Serverless, or Clusters | Runpod Secure Cloud: H100 PCIe 80 GB at $2.89/hour, H100 SXM 80 GB at $2.99/hour, and H100 NVL 94 GB at $3.19/hour. | Pod configurations include CPU and RAM; storage and deployment model affect total cost | | Lambda | Moving from self-serve H100 nodes to reserved AI clusters | Instances, 1-Click Clusters, and Superclusters | 8× H100 SXM 80 GB: $3.99 per GPU-hour for self-serve instances. | Listed instance is an eight-GPU node; taxes may apply | | CoreWeave | Running large, tightly coupled training workloads | Full NVIDIA HGX H100 nodes | 8× H100 node: $49.24/hour on demand; $19.51/hour spot in Europe or $19.71/hour spot in North America | Full-node pricing; calculated equivalent is about $6.16/GPU-hour on demand or $2.44–$2.46/GPU-hour spot, before other charges. | | Google Cloud | Running H100 workloads in GKE and the Google Cloud AI stack | A3 High, A3 Mega, and A3 Edge VMs | Varies by machine type, region, and provisioning model | Storage, networking, commitments, and capacity model affect total cost | | Amazon EC2 | Running H100 workloads in established AWS environments | One- or eight-GPU P5 instances and EC2 UltraClusters | Varies by region and purchasing model | Storage, data transfer, reservations, quotas, and adjacent services affect total cost | | Modal | Running bursty Python inference and batch functions | Serverless functions and containers | NVIDIA H100: $3.95/hour | CPU and memory are billed separately | These rates are not like for like. Included compute, storage, networking, interruption terms, operating-system costs, and platform services differ. ## What are the best cloud providers for NVIDIA H100 GPUs? The seven platforms below address different parts of the H100 deployment problem, from complete production applications to direct GPU infrastructure and serverless functions. ### 1. Northflank Choose Northflank when your H100 workload is part of a larger production AI application, especially when you need infrastructure choice and enterprise governance without building the surrounding platform yourself. - **H100 pricing:** The [Northflank GPU platform](https://northflank.com/gpu) lists NVIDIA H100 80 GB at $2.74/hour, including the GPU and its attached CPU and RAM. Billing is prorated to the second. - **Complete application platform:** Run H100 inference, training, and jobs alongside APIs, workers, databases, storage, CI/CD, autoscaling, secrets, logs, and metrics in one workflow. - **Infrastructure choice:** Use [Northflank Cloud](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-on-northflank-cloud), self-serve [BYOC](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud) across AWS, Google Cloud, Azure, Oracle, or CoreWeave, or eligible on-premises and bare-metal Kubernetes through BYOK. - **Enterprise governance:** BYOC and BYOK retain control over networking, IAM, regions, data residency, and cloud billing. Northflank also supports SSO, RBAC, audit logs, secure runtime options, and integrations with existing registries, Vault, and DNS. - **GPU operations:** The [GPU documentation](https://northflank.com/docs/v1/application/gpu-workloads/gpus-on-northflank) covers GPU-backed services and jobs, while the [optimisation guide](https://northflank.com/docs/v1/application/gpu-workloads/configure-and-optimise-workloads-for-gpus) covers scaling, storage, health checks, networking, and startup commands. Unlike providers that primarily supply GPU instances or clusters, Northflank manages the H100 workload and its surrounding application services across managed, BYOC, and BYOK infrastructure. Choose Northflank when you need to run H100 workloads alongside the rest of your production application, or when infrastructure choice, enterprise governance, and a consistent workflow across managed cloud, BYOC, and BYOK are priorities. The [Weights engineering team](https://northflank.com/blog/weights-uses-northflank-to-scale-to-millions-of-users-without-a-devops-team-ai-k8s) used Northflank to operate nine clusters, more than 40 microservices, and over 250 concurrent GPUs without a dedicated DevOps team. This example demonstrates production GPU orchestration rather than H100-specific usage. [Request NVIDIA H100 capacity](https://northflank.com/request/gpu), [get started (self-serve)](https://app.northflank.com/signup), or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss enterprise requirements. ### 2. Runpod Runpod suits teams that want self-serve H100 access and a choice between dedicated Pods, serverless workers, and multi-node clusters. - **H100 options and pricing:** Pods list PCIe 80 GB at $2.89/hour, SXM 80 GB at $2.99/hour, and NVL 94 GB at $3.19/hour, billed per second. - **Deployment models:** Pods provide dedicated instances, Serverless targets inference, and Clusters support multi-node jobs with shared storage. - **Scaling:** Clusters support up to 64 GPUs with shared storage, but H100 SXM cluster pricing requires contacting Runpod’s sales team. Choose Runpod when flexible access, form-factor choice, and Pod-level control are more important than operating the complete application stack on one platform. ### 3. Lambda Lambda suits teams that want dedicated AI infrastructure with a path from self-serve H100 instances to reserved clusters. - **Configuration and pricing:** The eight-GPU H100 SXM 80 GB node is listed at $3.99 per GPU-hour, plus applicable tax. - **Cluster options:** H100 clusters range from 16 to more than 2,000 GPUs. Published pricing covers terms from two weeks to one year, with longer commitments available through a sales-assisted path. - **Capacity model:** Instances are self-serve and first-come, while reservations use a sales-assisted path. Choose Lambda when dedicated AI infrastructure, full-node access, and a reservation path are the primary requirements. ### 4. CoreWeave CoreWeave suits organizations running large, tightly coupled training workloads on full HGX systems rather than renting a single general-purpose GPU instance. - **Configuration:** The NVIDIA HGX H100 node contains eight 80 GB GPUs, 128 vCPUs, 2,048 GB RAM, and 61.44 TB local storage. - **Pricing:** The node lists at $49.24/hour on demand. Spot is region-specific at $19.71/hour in North America and $19.51/hour in Europe. - **Hardware options:** The catalogue also includes H200, B200, B300, and RTX PRO 6000 systems. Choose CoreWeave when large distributed training and specialist HGX infrastructure take priority over single-GPU flexibility or a broader application platform. ### 5. Google Cloud Google Cloud suits organizations that want H100 capacity inside an established environment with existing data, networking, governance, GKE, and managed AI services. - **Configurations:** A3 High offers one, two, four, or eight H100 80 GB GPUs. A3 Mega is a fixed eight-GPU configuration for large-scale training and serving, while A3 Edge is a fixed eight-GPU configuration designed for serving in selected regions. - **Provisioning:** Smaller A3 High shapes require Spot or Flex-start; Google recommends GKE or Slurm for A3 Mega. - **Pricing:** Rates vary by machine, region, and provisioning model, with quotas and capacity affecting planning. Choose Google Cloud when native GKE, data, and AI service integration are more important than a simpler specialist-cloud workflow. If you need to keep H100 workloads, data, networking, IAM, and cloud billing within your Google Cloud account without taking on the operational overhead of building and maintaining the surrounding application platform, [Northflank BYOC for Google Cloud](https://northflank.com/cloud/gcp) provides a managed layer for orchestration, deployment, scaling, CI/CD, observability, databases, and GPU workloads. This gives enterprises greater control over data residency, security, and existing Google Cloud commitments while reducing the infrastructure their platform teams must operate directly. ### 6. Amazon EC2 Amazon EC2 suits organizations that want H100 capacity inside established AWS IAM, VPC, storage, automation, governance, procurement, and managed-service workflows. - **Configurations:** P5 includes one-GPU `p5.4xlarge` and eight-GPU `p5.48xlarge` shapes using H100 80 GB GPUs. - **Networking and scale:** The eight-GPU shape provides EFA, GPUDirect RDMA, 3,200 Gbps networking, and 900 GB/s NVSwitch; EC2 UltraClusters extend P5 to large fleets. - **Pricing:** Costs vary by region and purchase model, with storage, transfer, reservations, and quotas affecting the bill. Choose Amazon EC2 when AWS identity, networking, purchasing, and service integration determine the architecture. If you need to keep H100 workloads, data, networking, IAM, and cloud billing within your AWS account without taking on the operational overhead of building and maintaining the surrounding application platform, [Northflank BYOC for AWS](https://northflank.com/cloud/aws) provides a managed layer for orchestration, deployment, scaling, CI/CD, observability, databases, and GPU workloads. This helps enterprises retain control over data residency, security, and existing AWS commitments while reducing the infrastructure their platform teams must operate directly. ### 7. Modal Modal suits Python-centric teams running bursty inference, batch processing, and functions that benefit from per-second execution and scale-to-zero economics. - **Configuration:** Modal supports one to eight NVIDIA H100 SXM GPUs per container. - **Pricing:** Modal lists NVIDIA H100 GPU tasks at $3.95/hour. CPU and memory are billed separately. - **Execution model:** Developers assign H100 GPUs to Python functions. - **Capacity behavior:** Modal may automatically upgrade an H100 request to an H200. Multi-node training is currently in private beta at this time of writing. **Choose Modal** for Python-based inference and batch workloads that fit a GPU-backed function model. ## How should you choose an NVIDIA H100 cloud provider? Match the provider to your application’s operating model rather than one hourly rate. Choose Northflank for complete production AI applications, enterprise BYOC, or BYOK; Runpod for flexible H100 access; Lambda for dedicated nodes and reservations; CoreWeave for large HGX clusters; Google Cloud or Amazon EC2 for native hyperscaler integration; and Modal for Python-based inference and batch functions. Also consider Microsoft Azure when Azure integration or confidential H100 NVL computing is a primary requirement. For steady workloads, calculate monthly infrastructure and operational costs. For variable workloads, test availability, startup behavior, scaling, interruption risk, and the billable execution window. See [How much does an NVIDIA H100 GPU cost?](https://northflank.com/blog/how-much-does-an-nvidia-h100-gpu-cost) for a more detailed cost breakdown. ## Frequently asked questions about NVIDIA H100 cloud providers ### How much does it cost to rent an NVIDIA H100 in the cloud? Pricing depends on the configuration and billing model. Northflank lists H100 80 GB at $2.74 per GPU-hour with its attached CPU and RAM. CoreWeave lists a full eight-GPU HGX H100 node at $49.24/hour on demand, with spot pricing of $19.71/hour in North America and $19.51/hour in Europe. These rates are not directly comparable because node size, storage, networking, interruption risk, and commitments differ. Read [How much does an NVIDIA H100 GPU cost?](https://northflank.com/blog/how-much-does-an-nvidia-h100-gpu-cost) for a fuller breakdown. ### Should you choose H100 PCIe, SXM, or NVL? PCIe suits workloads that need single-GPU flexibility. SXM is used in tightly connected multi-GPU systems, while H100 NVL provides 94 GB of memory per GPU for memory-intensive inference. Choose based on memory, topology, software compatibility, and workload behavior. ### Is an H100 still worth renting in 2026? Yes, when your workload benefits from Hopper software support, 80 GB of GPU memory, FP8, or multi-GPU infrastructure. H200 and Blackwell GPUs may suit workloads that need more memory or newer hardware, while smaller inference workloads may cost less on an L4 or A100. ### Which H100 cloud provider is best for inference? Choose Northflank when inference is part of a complete production application with APIs, workers, databases, CI/CD, and observability. Runpod provides Pod and Serverless options, Google Cloud A3 Edge is designed for serving in supported regions, and Modal fits Python-based inference functions. ### Which H100 cloud provider is best for model training? Lambda and Runpod fit single-node and smaller training workloads. CoreWeave fits large, tightly coupled HGX clusters. Amazon EC2 and Google Cloud fit organizations that want to keep training data, identity, networking, and managed services within an existing hyperscaler environment. ### Can enterprises run H100 workloads in their own cloud account? Yes, when the platform supports customer-cloud deployment. Northflank’s self-serve BYOC lets teams deploy H100 workloads in their cloud account while retaining control over infrastructure, networking, IAM, regions, data residency, and cloud billing. Read the guide to [deploying GPUs in your own cloud](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud). ## Related articles to NVIDIA H100 cloud providers - [How much does an NVIDIA H100 GPU cost?](https://northflank.com/blog/how-much-does-an-nvidia-h100-gpu-cost): Compare H100 specifications, purchase costs, cloud pricing, and deployment options. - [Rent H100 GPU: Pricing, performance, and where to get one](https://northflank.com/blog/rent-h100-gpu-pricing-performance-and-where-to-get-one): Review the decisions involved in renting H100 capacity. - [Best cloud services for renting high-performance GPUs on demand](https://northflank.com/blog/best-cloud-services-for-renting-high-performance-gpus-on-demand): Compare a wider selection of GPU services. - [Best serverless GPU providers](https://northflank.com/blog/the-best-serverless-gpu-cloud-providers): Evaluate scale-to-zero GPU platforms for inference. - [Best options for BYOC in cloud computing](https://northflank.com/blog/best-options-for-byoc-in-cloud-computing): Compare platforms that run in your own cloud account. - [Top GPU sandboxes for AI agents](https://northflank.com/blog/top-gpu-sandboxes-for-ai-agents): Compare governed GPU execution environments for agent workloads.

Best NVIDIA A100 GPU cloud providers in 2026

2026-07-31T17:08:00.000Z

Choosing an NVIDIA A100 cloud provider is not just a matter of finding the lowest hourly rate. The right option depends on whether you need 40 GB or 80 GB of GPU memory, one GPU or a connected multi-GPU node, and raw infrastructure or a platform that also manages the surrounding application. This guide compares five NVIDIA A100 cloud providers by GPU configuration, deployment workflow, access model, pricing scope, and fit for training, fine-tuning, inference, and high-performance computing (HPC). ## TL;DR: Best NVIDIA A100 GPU cloud providers - **Northflank** combines managed A100 40 GB and 80 GB capacity with services, jobs, CI/CD, autoscaling, observability, databases, and storage. You can also use self-serve BYOC or import an existing Kubernetes cluster through BYOK, including eligible on-premises and bare-metal clusters with compatible GPU-enabled nodes. - **Amazon EC2** provides fixed eight-GPU P4 instances with NVIDIA A100 40 GB or 80 GB GPUs for workloads running within AWS. - **Google Cloud Compute Engine** offers A2 configurations from one A100 to large multi-GPU VM shapes, with 40 GB and 80 GB options. - **Lambda Cloud** provides A100 VMs through its UI, API, and CLI, with per-GPU pricing billed by the minute. - **Runpod Serverless** provides A100 80 GB workers for autoscaled inference, including workers that scale to zero when idle. Running AI in production often requires more than an A100 instance. You need to connect training, fine-tuning, or inference to APIs, queues, workers, databases, storage, networking, deployment workflows, and monitoring without giving up infrastructure ownership or governance. The [Northflank GPU platform](https://northflank.com/product/gpu-paas) runs those components through one workflow across [Northflank Cloud](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-on-northflank-cloud), [self-serve BYOC](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud), or an eligible existing Kubernetes cluster through BYOK. You can keep workloads in your cloud or VPC, or use eligible on-premises and bare-metal clusters through BYOK. Northflank supports existing networking, IAM, cloud billing, and governance requirements. If you have a smaller engineering team, you can run GPU workloads and supporting application services without building a separate platform stack. [Request NVIDIA A100 or other GPU capacity](https://northflank.com/request/gpu) for production, volume, or reservation requirements. You can also [get started with Northflank](https://app.northflank.com/signup) self-serve or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ## What to look for in an A100 cloud provider Evaluate each provider across the same practical criteria before comparing prices or choosing a deployment model. - **GPU configuration:** Compare A100 40 GB and 80 GB options, PCIe and SXM form factors, GPU count, and interconnect. A single GPU for development is a different product from an eight-GPU node designed for distributed training. - **Operating model:** Check whether the provider offers complete VMs, GPU-focused infrastructure, serverless workers, or an application platform. Also account for quotas, regional capacity, deployment tooling, and how much infrastructure your team must operate. - **Total workload cost:** Full-machine, bundled GPU, GPU-only, and serverless GPU-second rates include different resources. Check whether CPU and RAM are included, then account for storage, network transfer, idle time, interruption risk, and commitments rather than comparing one headline figure. These five providers represent distinct A100 operating models: an application platform, two hyperscale clouds, a GPU-focused VM provider, and a serverless GPU platform. Other cloud providers also offer A100 capacity. ## Best A100 cloud providers at a glance The table below compares deployment models, A100 prices, and the resources included with each option. Prices are accurate as at 30 July 2026. | Provider | Best for | Deployment | A100 price | Pricing scope | | --- | --- | --- | --- | --- | | Northflank | Running GPU workloads with the wider production application | Northflank Cloud, self-serve BYOC, or eligible existing Kubernetes through BYOK | A100 40 GB: $1.42/hr; A100 80 GB: $1.76/hr | GPU rates include attached CPU and RAM; billed per second | | Amazon EC2 | Running eight-GPU training nodes in an AWS environment | Fixed P4 EC2 VMs with quota and capacity controls | Capacity Blocks, current effective rate: 8×A100 40 GB at $11.80/instance-hr; 8×A100 80 GB at $17.712/instance-hr in selected US regions | Full eight-GPU instance; Capacity Block rates vary with supply and demand and are not standard EC2 On-Demand prices | | Google Cloud Compute Engine | Scaling across a broad range of A2 VM shapes | A2 VMs or GKE nodes | Varies by A2 shape, region, and on-demand, Spot, or committed-use model | Bundled accelerator-optimised VM price; storage and networking can add cost | | Lambda Cloud | Launching preconfigured GPU VMs | Single- or multi-GPU cloud instances | 1× A100 40 GB SXM or PCIe, or 2×/4× A100 40 GB PCIe: $1.99/GPU-hr; 8× A100 40 GB SXM: $1.99/GPU-hr; 8× A100 80 GB SXM: $2.79/GPU-hr | Per-GPU price billed by the minute; applicable sales tax extra | | Runpod Serverless | Serving variable inference traffic with autoscaled workers | Serverless Flex or Active workers | Serverless A100 80 GB: $2.72/GPU-hr | Usage-based Serverless worker rate; storage billed separately | These rates are not like for like. Included GPU count, CPU, RAM, storage, networking, purchasing terms, and platform services differ. ## What are the best cloud providers for NVIDIA A100 GPUs? Match each provider's operating model to the A100 workload, infrastructure requirements, and level of control your team needs. ### 1. Northflank Choose Northflank when your A100 workload is one part of a larger production application. It is particularly relevant when you have limited platform-engineering capacity or need infrastructure choice, governance, and a consistent workflow across environments. - **A100 choice and pricing:** The [Northflank GPU platform](https://northflank.com/product/gpu-paas) offers A100 40 GB at $1.42/hour and A100 80 GB at $1.76/hour, as at 30 July 2026. Per-second rates include the GPU and attached CPU and RAM; storage, networking, and separate CPU workloads cost extra. Check the [pricing calculator](https://northflank.com/pricing) for a current estimate. Enterprise pricing may apply to high-scale or custom deployments. - **Complete application platform:** A100-backed inference, training, and batch jobs can run beside APIs, workers, scheduled jobs, managed databases, persistent volumes, object storage, networking, secrets, CI/CD, autoscaling, logs, metrics, and release workflows. Engineers use the same UI, CLI, API, and Git-based workflow for CPU and GPU services. - **Infrastructure choice:** You can [deploy GPUs on Northflank Cloud](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-on-northflank-cloud), [deploy GPUs in your own cloud](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud), or import an existing Kubernetes cluster through BYOK. BYOC covers providers including AWS, Google Cloud, Microsoft Azure, Oracle, and CoreWeave. BYOK can extend the workflow to eligible on-premises and bare-metal Kubernetes clusters, provided they meet Northflank's import requirements and have compatible GPU-enabled nodes available for workload scheduling. - **Governance and integration:** Enterprise capabilities include SSO with SAML or OIDC, audit logs, global backups and HA/DR options, secure runtime and on-premises deployment, plus integrations for existing registries, Vault, and DNS. BYOC and BYOK can retain control over infrastructure, regional placement, networking, IAM, data residency, and cloud billing. - **GPU operations:** Use the [GPU documentation](https://northflank.com/docs/v1/application/gpu-workloads/gpus-on-northflank) to deploy GPU-backed services and jobs. Use the [configuration and optimisation guide](https://northflank.com/docs/v1/application/gpu-workloads/configure-and-optimise-workloads-for-gpus) for compatible images, CPU and memory sizing, persistent storage, scaling, health checks, ports, and startup commands. Northflank also supports NVIDIA MIG and time slicing, although time-sliced workloads do not receive fault or memory isolation from one another. The distinction between these providers is the scope each one manages. Amazon EC2 and Google Cloud provide native infrastructure that your engineering team configures and operates. Lambda Cloud provides preconfigured GPU VMs, while Runpod Serverless provides autoscaling inference workers. Northflank manages the GPU workload and its surrounding application services on Northflank Cloud, in your own cloud through BYOC, or on eligible existing Kubernetes clusters through BYOK. The Weights engineering team used Northflank to operate nine clusters across AWS, Google Cloud, and Microsoft Azure, more than 40 microservices, and over 250 concurrent GPUs without a dedicated DevOps team. The [Weights case study](https://northflank.com/blog/weights-uses-northflank-to-scale-to-millions-of-users-without-a-devops-team-ai-k8s) is not specific to the A100, but it demonstrates this wider GPU and application orchestration model at production scale. [Request NVIDIA A100 or other GPU capacity](https://northflank.com/request/gpu) for production, volume, or reservation requirements. You can also [get started with Northflank](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, data residency, or migration requirements. ### 2. Amazon EC2 Choose Amazon EC2 when you already operate data, networking, security controls, and ML workloads on AWS. Its P4 family packages A100 GPUs into fixed multi-GPU VMs. - **GPU configuration:** `p4d.24xlarge` contains eight A100 40 GB GPUs. `p4de.24xlarge` contains eight A100 80 GB GPUs. - **Host resources:** Both shapes provide 96 vCPUs and 1,152 GiB of system memory. - **Purchasing options:** You can use on-demand or Spot instances, commitments, or Capacity Blocks for ML where available. - **AWS fit:** P4 instances can remain within an existing AWS architecture, account-governance model, and procurement relationship. Choose Amazon EC2 when your workload can use a complete eight-GPU node and your team wants direct control within existing AWS identity, VPC, automation, governance, and purchasing workflows. P4 may be oversized for development or smaller inference workloads, and its full-instance or per-accelerator equivalent is not directly comparable with an independently rented single A100. If you need to keep workloads, data, networking, IAM, and cloud billing within your AWS account without building and maintaining the surrounding application platform, [Northflank BYOC for AWS](https://northflank.com/cloud/aws) provides a managed layer for orchestration, deployment, scaling, CI/CD, observability, databases, and GPU workloads. This helps you retain control over data residency, security, and existing AWS commitments while reducing the infrastructure your platform team operates directly. ### 3. Google Cloud Compute Engine Choose Google Cloud Compute Engine when you want both single-GPU and large multi-GPU VM shapes inside the Google Cloud ecosystem. - **GPU configuration:** A2 Standard uses A100 40 GB GPUs. A2 Ultra uses A100 80 GB GPUs and includes Local SSD. - **Scaling range:** A2 Ultra ranges from one to eight GPUs per VM. A2 Standard also includes the 16-GPU `a2-megagpu-16g` shape. - **Platform integration:** A2 VMs integrate with Google Kubernetes Engine and Google Cloud AI services. - **Purchasing options:** A2 uses bundled accelerator-optimised VM pricing with on-demand, committed-use, and Spot VM options. Choose Google Cloud Compute Engine when you want direct control over A2 VMs or GKE nodes and already have the expertise to operate the surrounding Google Cloud infrastructure. Check project quota, regional support, and live capacity because an A2 shape may be supported without being immediately allocatable in every project or region. If you need to keep workloads, data, networking, IAM, and cloud billing within your GCP account without taking on the operational overhead of building and maintaining the surrounding application platform, [Northflank BYOC for GCP](https://northflank.com/cloud/gcp) provides a managed layer for orchestration, deployment, scaling, CI/CD, observability, databases, and GPU workloads. This gives you greater control over data residency, security, and existing GCP commitments while reducing the infrastructure your platform team must operate directly. ### 4. Lambda Cloud Choose Lambda Cloud when you want a preconfigured ML environment and a direct VM deployment workflow. - **GPU configuration:** Choose a single A100 40 GB SXM or PCIe instance, a two- or four-GPU A100 40 GB PCIe instance, or an eight-GPU A100 40 GB or 80 GB SXM instance. - **Interface:** Instances can be launched and managed through the UI, API, or CLI. - **Pricing:** As at 30 July 2026, the A100 40 GB SXM and PCIe configurations cost $1.99 per GPU-hour, while the eight-GPU A100 80 GB SXM configuration costs $2.79 per GPU-hour, plus applicable sales tax. Usage is billed in one-minute increments. - **Included workflow:** Lambda Cloud includes its ML software stack and does not charge egress fees for on-demand instances. Choose Lambda Cloud when direct VM access and a preconfigured ML stack are the main requirements. Capacity is available on a first-come basis, and the available A100 memory and form factor depend on the instance size, so your preferred configuration may not always be immediately available. ### 5. Runpod Serverless Choose Runpod Serverless when your inference workload benefits from autoscaled workers rather than persistent VMs. - **GPU configuration:** Runpod Serverless offers A100 80 GB GPUs for autoscaling inference workers. - **Worker models:** Flex workers scale to zero when idle. Active workers remain running for consistent traffic and low-latency requirements. - **Pricing:** As at 30 July 2026, Runpod lists A100 80 GB Serverless Flex workers at an hourly equivalent of $2.72. Serverless usage is billed per second. Storage is billed separately, and dedicated Pods use different pricing. - **Workload fit:** The worker model suits variable inference demand where scaling behavior is more important than maintaining a persistent machine. Choose Runpod Serverless when your workload benefits from autoscaling workers. These rates apply only to Serverless compute. Runpod Pods use a separate deployment and pricing model for persistent GPU instances. ## How to choose an A100 cloud provider for your workload Choose based on the layer you want the provider to manage: - Choose **Northflank** when you need A100 services or jobs alongside application infrastructure, with a choice of managed cloud, BYOC, or BYOK. - Choose **Amazon EC2** when an eight-GPU A100 node fits the workload and the wider system already operates on AWS. - Choose **Google Cloud Compute Engine** when you need a broad range of A2 sizes inside Google Cloud. - Choose **Lambda Cloud** when direct VM access and a preconfigured ML stack are the priorities. - Choose **Runpod Serverless** when the workload maps naturally to autoscaled inference workers. Before reserving capacity, confirm the exact GPU memory and form factor, GPU count and interconnect, target region, quota or approval, live capacity, CPU and RAM allocation, storage and network charges, interruption terms, and minimum commitment. Test a representative workload before relying on hourly rates alone. ## Frequently asked questions about NVIDIA A100 GPU cloud providers ### Is the NVIDIA A100 still a good cloud GPU in 2026? Yes, when its 40 GB or 80 GB memory, mature CUDA support, availability, and price-performance fit the workload. A100 capacity remains available for training, fine-tuning, inference, and HPC. For new deployments, benchmark the A100 against newer accelerators because a lower hourly price does not necessarily mean a lower cost per completed job. ### Should I choose an A100 40 GB or A100 80 GB instance? Choose 80 GB when model weights, batches, activations, or working data cannot fit comfortably within 40 GB. A 40 GB option can cost less when the workload fits. Also check PCIe or SXM form factor and multi-GPU interconnect because memory capacity alone does not define the complete node. ### Can I rent a single NVIDIA A100 GPU? Yes. Northflank lets you deploy a single A100 40 GB or 80 GB GPU for a service or job on Northflank Cloud, with BYOC and BYOK options when you need to use your own infrastructure. Google Cloud Compute Engine and Lambda Cloud also offer single-A100 instances, while Runpod Serverless provides A100 workers backed by a single GPU. Amazon EC2 P4 instances start with eight A100 GPUs. ### What should I check before reserving A100 capacity? Confirm the region, quota or access approval, live capacity, GPU memory and form factor, multi-GPU topology, CPU and RAM allocation, persistent storage, egress charges, interruption terms, minimum commitment, software image, and monitoring setup. ## Related articles to NVIDIA A100 GPU cloud providers - [How much does an NVIDIA A100 GPU cost?](https://northflank.com/blog/nvidia-a100-gpu-cost) explains the cost of buying and renting A100 capacity. - [12 best GPU cloud providers for AI and ML](https://northflank.com/blog/12-best-gpu-cloud-providers) compares a broader range of providers and GPU models. - [NVIDIA H100 vs A100](https://northflank.com/blog/h100-vs-a100) compares the two GPU generations by architecture, memory, workload, and cloud cost. - [Deploy GPUs on Northflank Cloud](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-on-northflank-cloud) walks through creating a GPU-enabled project and workload. - [Best options for BYOC in cloud computing](https://northflank.com/blog/best-options-for-byoc-in-cloud-computing) compares approaches for keeping workloads in your own cloud account.

What's the difference between Spot GPUs and reserved GPUs?

2026-07-31T14:00:00.000Z

Spot GPUs and reserved GPUs both reduce infrastructure costs compared to on-demand pricing, but they solve different problems. Spot GPUs offer the lowest prices in exchange for interruption risk, while reserved GPUs provide guaranteed capacity in return for a long-term commitment. This guide explains the differences between spot and reserved GPUs, their tradeoffs, and how to choose the right pricing model for your AI workloads. ## TL;DR: Spot GPUs vs reserved GPUs - **Spot GPUs** are the cheapest option but can be interrupted at any time, making them best for fault-tolerant workloads that can checkpoint and resume. - **Reserved GPUs** offer guaranteed capacity and lower long-term pricing in exchange for a one- to three-year commitment, making them ideal for predictable, continuously running workloads. - If your GPU requirements are still evolving, on-demand GPUs provide the flexibility to scale without long-term commitments. > [Northflank](https://northflank.com/product/gpu-paas) provides on-demand [GPU workloads](https://northflank.com/product/gpu-paas) with no long-term commitments or reserved contracts. Deploy [H100](https://northflank.com/blog/how-much-does-an-nvidia-h100-gpu-cost), [H200](https://northflank.com/blog/how-much-does-an-nvidia-b200-gpu-cost), [A100](https://northflank.com/blog/nvidia-a100-gpu-cost), [L4](https://northflank.com/blog/how-much-does-an-nvidia-l4-gpu-cost), L40S, and B200 GPUs alongside applications, [databases](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), [inference services](https://northflank.com/product/gpu-paas), and [AI sandboxes](https://northflank.com/product/sandboxes) in a single platform, or deploy into your own cloud with [BYOC](https://northflank.com/product/bring-your-own-cloud) when you need dedicated GPU infrastructure. [Get started (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > ## Spot GPUs vs reserved GPUs: key differences Although both pricing models reduce infrastructure costs compared to on-demand pricing, they solve different problems. Spot GPUs prioritise lower costs by using spare cloud capacity that providers can reclaim when demand increases. Reserved GPUs prioritise guaranteed capacity and predictable pricing in exchange for a long-term commitment. | Feature | Spot GPUs | Reserved GPUs | | --- | --- | --- | | Pricing | Lowest hourly cost | Discounted compared to on demand | | Availability | No guarantee | Guaranteed for contract term | | Interruptions | Can be reclaimed by the provider | None | | Commitment | None | Typically 1 to 3 years | | Idle cost | None | Pay even when unused | | Best for | Batch training, hyperparameter tuning, offline inference | Continuous training, production inference, long running workloads | | Main tradeoff | Lowest cost, highest risk | Lower cost, less flexibility | ## What is a spot GPU? Spot GPUs are GPU instances sold using unused cloud capacity. Rather than leaving GPUs idle, cloud providers offer them at discounted rates until that capacity is needed elsewhere. The tradeoff is that spot instances can be reclaimed with little warning. AWS Spot Instances, for example, typically provide a two-minute interruption notice before termination. Other providers have similar behaviour. This means applications running on spot GPUs must be designed to recover from interruptions automatically. Training jobs should checkpoint frequently, long-running processes should save intermediate state, and orchestration systems should be able to restart workloads from the latest checkpoint. Without this engineering, a single interruption can erase hours of compute. ### Spot GPUs are best for - Distributed training with checkpointing - Hyperparameter tuning - Dataset preprocessing - Offline batch inference - Cost-sensitive research workloads ### Spot GPUs are not suitable for - Production inference - Interactive AI applications - Deadline-driven training jobs - Workloads that cannot recover automatically ## What is a reserved GPU? Reserved GPUs allow you to commit to GPU capacity for a fixed period, usually one to three years. In return, providers offer lower hourly rates and guarantee capacity is available when you need it. Unlike spot GPUs, reserved capacity cannot be reclaimed by the provider during the reservation period. Reserved capacity works well for organisations running workloads continuously. When GPU utilisation remains consistently high, reserved pricing can significantly reduce long-term infrastructure costs. The tradeoff is flexibility. You're committing to pay for capacity whether it's fully utilised or not. If workload requirements change midway through a reservation, or utilisation drops unexpectedly, reserved GPUs may become more expensive overall than using on-demand capacity. ### Reserved GPUs are best for - Production inference platforms - Continuous model training - Stable enterprise AI workloads - Predictable GPU demand ### Reserved GPUs are not suitable for - Early-stage startups - Research environments - Seasonal workloads - Teams with unpredictable GPU requirements ## Should you choose spot or reserved GPUs? The right choice depends less on the price per hour and more on how predictable your workloads are. - Choose **spot GPUs** if reducing infrastructure costs is your highest priority and your workloads can tolerate interruptions. Batch processing, distributed training, hyperparameter tuning, and offline inference are all good candidates because they can recover automatically when interrupted. - Choose **reserved GPUs** if your workloads run continuously and require guaranteed capacity. Production inference services, recurring training pipelines, and enterprise AI platforms often benefit from predictable pricing and guaranteed availability. If you're still discovering your workload patterns, starting with on-demand GPUs is often the safest option. Once utilisation becomes predictable, you can introduce reserved capacity while continuing to use spot GPUs for fault-tolerant workloads. In practice, many organisations reserve GPU capacity for predictable production workloads while using spot GPUs wherever interruption is acceptable. ## How Northflank handles GPU workloads Running GPU workloads in production is about more than accessing GPU compute. Most AI applications also need inference servers, databases, object storage, deployment pipelines, autoscaling, observability, secrets management, and networking to support training and inference. [Northflank](https://northflank.com/product/gpu-paas) brings all of these together in a single platform. Deploy GPU workloads across 18+ GPU types, including [H100](https://northflank.com/blog/how-much-does-an-nvidia-h100-gpu-cost), [H200](https://northflank.com/blog/how-much-does-an-nvidia-b200-gpu-cost), [A100](https://northflank.com/blog/nvidia-a100-gpu-cost), [L4](https://northflank.com/blog/how-much-does-an-nvidia-l4-gpu-cost), L40S, B200, and GB300, alongside your applications, [managed databases](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), [AI sandboxes](https://northflank.com/product/sandboxes), and [inference services](https://northflank.com/product/gpu-paas) with no reserved commitments, long-term contracts, or vendor lock-in. ### What is Northflank? [Northflank](https://northflank.com/) is a platform for deploying and managing AI workloads in production. Deploy [GPU workloads](https://northflank.com/product/gpu-paas), [inference services](https://northflank.com/product/gpu-paas), applications, and databases together in a single platform with built-in CI/CD, autoscaling, and BYOC. [Sign up to get started](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to see how it fits your stack. > **Need GPU capacity planning?** For teams with consistent GPU requirements or specific availability needs, [request GPU capacity here](https://northflank.com/request/gpu) to explore volume options and reservations. > GPU workloads run in the same control plane as standard CPU services, [microVM sandboxes](https://northflank.com/product/sandboxes), [managed databases](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), and [application deployments](https://northflank.com/product/deployments). You get the same [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [SSO](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication), [secrets management](https://northflank.com/docs/v1/application/secure/security-on-northflank#secret-management), [audit logging](https://northflank.com/docs/v1/application/observe/audit-logs), and [BYOC](https://northflank.com/product/bring-your-own-cloud) across your entire stack without managing separate GPU infrastructure or billing relationships. Key features of GPU workloads on Northflank: - **Auto-scaling from zero:** Inference endpoints scale from zero to hundreds of GPUs based on traffic. Intelligent queuing prevents request drops during traffic spikes. - **GPU time-slicing:** Run multiple workloads on single GPUs with NVIDIA time-slicing. Share expensive H100s across development, testing, and small inference workloads. Improve utilisation by 2–4x. - **Integrated storage:** Co-locate GPU compute with managed databases, S3-compatible object storage, and persistent volumes for low-latency data access during training. - **Observability built in:** Real-time GPU utilisation, memory usage, and temperature monitoring. Track inference latency, throughput, and cost per workload. Integrated logging for training runs. - **Same DevEx across every cloud:** Deploy on [AWS](https://northflank.com/cloud/aws), [GCP](https://northflank.com/cloud/gcp), [Azure](https://northflank.com/cloud/azure), [Oracle](https://northflank.com/cloud/oci), [CoreWeave](https://northflank.com/cloud/coreweave), or [any GPU cloud](https://northflank.com/cloud/gpus) via BYOC. Same UI, CLI, and API regardless of provider. For enterprises that need GPU capacity inside their own cloud account, [Northflank BYOC](https://northflank.com/product/bring-your-own-cloud) deploys into your existing AWS, GCP, Azure, Oracle, or CoreWeave account. GPU workloads run inside your own VPC with no markup on underlying compute. For the most isolated environments, Northflank also supports a [forward-deployed control plane](https://northflank.com/enterprise) for defence technology companies, healthcare institutions, and financial services firms. **Northflank H100 pricing starts at $2.74/hour**, including compute, networking, storage, and platform management. No hidden fees. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to see how Northflank handles GPU workloads for your team. ## FAQ: spot GPUs vs reserved GPUs ### Which is cheaper, spot or reserved GPUs? Spot GPUs usually offer the lowest hourly pricing but can be interrupted at any time. Reserved GPUs cost more per hour than spot but provide guaranteed availability and predictable pricing. ### Can you use spot GPUs for production inference? Generally no. Production inference requires consistent availability, making reserved or on-demand GPUs a better choice. Spot GPUs are better suited for batch workloads that can tolerate interruptions. ### Should startups reserve GPUs? Usually not. Startups often have unpredictable infrastructure requirements and changing workload patterns. On-demand GPUs provide more flexibility until demand becomes consistent enough to justify reservations. ### What happens if I don't use reserved GPU capacity? You continue paying for it. Reserved GPU contracts typically charge for the agreed commitment period regardless of how much of the capacity is actually used. ### Can I combine spot and reserved GPUs? Yes. Many organisations reserve capacity for predictable production workloads while using spot GPUs for fault-tolerant batch processing and experimental workloads. ### Are reserved GPUs always cheaper than spot GPUs? No. Spot GPUs usually have the lowest hourly price, but they can be interrupted at any time. Reserved GPUs cost more per hour than spot, but provide guaranteed availability and predictable pricing. The better choice depends on whether your workload can tolerate interruptions. ## Conclusion Spot and reserved GPUs solve different problems. Spot GPUs minimise infrastructure costs but require workloads that can tolerate interruptions and recover automatically. Reserved GPUs provide guaranteed capacity and predictable pricing, making them the better choice for continuously running production workloads. For most organisations, the decision isn't choosing one or the other. It's deciding which workloads benefit from each. Reserve GPU capacity where demand is predictable, and use spot GPUs wherever interruption is acceptable and cost savings matter most. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ## Related articles - [How much does an NVIDIA L4 GPU cost?](https://northflank.com/blog/how-much-does-an-nvidia-l4-gpu-cost): Compare L4 specifications, pricing models, and Northflank deployment options. - [Top GPU sandboxes for AI agents](https://northflank.com/blog/top-gpu-sandboxes-for-ai-agents): Compare isolated GPU execution platforms for agent workloads that need direct accelerator access. - [GPU workloads on Northflank](https://northflank.com/gpu): Review supported GPUs and deployment paths for inference, training, and compute-intensive workloads. - [How much does an NVIDIA A100 GPU cost?](https://northflank.com/blog/nvidia-a100-gpu-cost) Compare cloud pricing for the 40 GB and 80 GB A100 variants. - [How much does an NVIDIA H100 GPU cost?](https://northflank.com/blog/how-much-does-an-nvidia-h100-gpu-cost) Review H100 pricing for higher-throughput inference and training. - [How much does an NVIDIA B200 GPU cost?](https://northflank.com/blog/how-much-does-an-nvidia-b200-gpu-cost) Understand pricing for NVIDIA Blackwell infrastructure.

What are computers for AI agents?

2026-07-31T14:00:00.000Z

AI agents do more than generate text. They write and execute code, call APIs, browse websites, access files, and interact with external tools. To perform those actions, every AI agent needs somewhere to run. That execution environment is effectively the computer for an AI agent. While local machines are common during development, production AI agents typically run inside isolated cloud sandboxes that provide the security, scalability, and governance needed to operate at scale. ## TL;DR: What are computers for AI agents? - AI agents need a place to execute code, call tools, access files, and interact with external systems. In production, that "computer" is usually an isolated cloud execution environment rather than a physical machine. - Modern AI agent platforms use sandboxed execution environments with strong isolation, fast startup times, and automatic cleanup so every agent session runs independently. - [Northflank](https://northflank.com/) provides the execution layer for AI agents with [microVM-isolated sandboxes](https://northflank.com/product/sandboxes), [GPU workloads](https://northflank.com/product/gpu-paas), [enterprise networking](https://northflank.com/docs/v1/application/network/networking-on-northflank), [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [SSO](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication), [secrets management](https://northflank.com/docs/v1/application/secure/security-on-northflank#secret-management), [audit logging](https://northflank.com/docs/v1/application/observe/audit-logs), and [self-serve BYOC](https://northflank.com/product/bring-your-own-cloud) support in a single platform. > Running AI agents requires more than compute. Northflank combines sandbox environments, GPU workloads, databases, networking, and deployment workflows in one platform, so teams can build and scale AI agents without managing the underlying infrastructure. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). > ## What is a computer for an AI agent? A computer for an AI agent is the environment where the agent executes actions after deciding what to do. While the AI model handles reasoning and planning, the computer provides the CPU, memory, storage, networking, and runtime needed to execute code, call APIs, access files, and interact with external systems. For simple projects, that computer might be a laptop, desktop workstation, or virtual machine. As AI agents move into production, however, teams increasingly run them inside isolated cloud sandboxes that can start in milliseconds, execute safely, and automatically shut down when work is complete. The computer isn't the AI model itself. It's the execution environment that allows the model to safely interact with the outside world. ## Types of computers for AI agents The right computer for an AI agent depends on what the agent is doing and where it runs. While many developers start by running agents locally, production deployments typically move to cloud-based execution environments that provide stronger isolation, scalability, and operational controls. | Computer type | Best for | Limitations | | --- | --- | --- | | Laptop or desktop | Local development and testing | Limited resources and difficult to scale | | GPU workstation | Running local models and experimentation | Expensive and tied to a single machine | | Virtual machine | Small production deployments | Slower startup and shared operational overhead | | Containers | Stateless applications and APIs | Shared kernel makes them less suitable for untrusted code | | Sandbox environments | Production AI agents | Built for isolated, short-lived execution at scale | While local computers are ideal for development, most production AI agents eventually move to sandbox environments because they provide stronger isolation, better scalability, and built-in operational controls. ## What does an AI agent actually need to run? Every AI agent relies on two different types of compute. ### 1. The reasoning layer This is the large language model (LLM) that interprets prompts, plans actions, and decides what to do next. The model may run through an API such as OpenAI or Anthropic, or on self-hosted inference infrastructure powered by frameworks like vLLM or Triton. The reasoning layer decides **what** to do. ### 2. The execution layer The execution layer is where those decisions become actions. This is where an AI agent: - Executes code - Reads and writes files - Calls APIs - Uses MCP servers and external tools - Browses websites - Connects to databases - Runs shell commands The execution layer determines **how those actions are carried out.** For production AI agents, this execution layer is often far more difficult to build than the reasoning layer. It must isolate every session, manage credentials securely, scale on demand, and prevent one agent from affecting another. ## Why can't AI agents just run in a container? Containers are lightweight, portable, and widely used for modern applications. However, AI agents execute code, call external tools, and use sensitive credentials, making them very different from traditional workloads. Because containers share the host operating system kernel, they don't provide the strongest isolation for executing untrusted or AI-generated code. That's why production AI agent platforms increasingly run each session inside an isolated sandbox with its own runtime, filesystem, network boundaries, and credentials. ## Why sandbox environments have become the standard A sandbox is an isolated execution environment designed to safely run code without affecting the underlying host or other running workloads. Every AI agent session receives its own sandbox with dedicated compute, temporary storage, networking, and runtime configuration. When the task finishes, the entire environment is automatically destroyed. This approach provides several advantages: - One compromised agent cannot affect another. - Credentials remain isolated to a single session. - Temporary files disappear when execution finishes. - Compute resources can scale up and down automatically. - Thousands of agents can run concurrently without sharing execution environments. Platforms like [Northflank](https://northflank.com/) build AI agent infrastructure around sandbox environments because they provide the isolation, scalability, and operational controls required for production deployments. ## Why microVMs are the preferred isolation model Not every sandbox provides the same level of isolation. Many platforms use containers because they start quickly and consume few resources. While containers work well for trusted workloads, they still share the host operating system kernel. MicroVMs provide a much stronger isolation boundary by giving every execution environment its own lightweight virtual machine and dedicated kernel. Popular technologies include: - **Firecracker**, originally developed for AWS Lambda and Fargate. - **Kata Containers with Cloud Hypervisor**, which combines container workflows with virtual machine isolation. Each approach balances startup time, compatibility, and isolation differently, but all provide stronger security boundaries than traditional containers. [Northflank](https://northflank.com/) supports multiple sandbox isolation technologies, allowing teams to choose the right balance of performance and security for different workloads. ## What should an AI agent execution platform provide? Running one AI agent is straightforward. Running thousands securely and reliably is a much harder infrastructure problem. A production-ready execution platform should provide more than just CPU and memory. 1. **Fast startup:** Execution environments should start in milliseconds so agents can respond quickly. 2. **Strong isolation:** Every session should have its own runtime, filesystem, and network boundaries to prevent agents from affecting one another. 3. **Automatic cleanup:** Sandboxes should automatically shut down and remove temporary files, credentials, and resources when work is complete. 4. **Secrets management:** API keys and credentials should be injected securely at runtime and never shared between sessions. 5. **Network controls:** Teams should be able to define exactly which services an agent can access. 6. **Observability:** Logs, metrics, and audit trails should make it easy to monitor, troubleshoot, and investigate agent activity. 7. **Elastic scaling:** The platform should scale automatically from a handful of sessions to thousands without manual provisioning. 8. **Bring Your Own Cloud (BYOC):** Teams should be able to deploy AI agent infrastructure into their own AWS, Azure, GCP, Oracle, CoreWeave, or on-premises environment while using the same platform and workflows. 9. **GPU support:** CPU and GPU workloads should run together, allowing agents to perform inference, image processing, and other accelerated workloads. ## How Northflank provides the execution layer for AI agents Running AI agents in production requires much more than isolated compute. Teams also need deployment workflows, secrets management, networking, observability, GPU infrastructure, identity management, and governance. Rather than stitching these together across multiple services, [Northflank](https://northflank.com/) provides a single platform for deploying, running, and scaling AI agents in production. ### What is Northflank? Northflank is a platform for building and operating production AI workloads. [Sandbox environments](https://northflank.com/product/sandboxes), [GPU workloads](https://northflank.com/product/gpu-paas), applications, inference services, [databases](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank), object storage, and [networking](https://northflank.com/docs/v1/application/network/networking-on-northflank) all run within the same control plane. Whether you're deploying coding agents, internal copilots, autonomous workflows, or multi-agent systems, Northflank provides the infrastructure required to run them securely at scale. Sign up to get started or book a demo. > **Need dedicated capacity or deployment inside your own cloud?** [Northflank BYOC](https://northflank.com/product/bring-your-own-cloud) lets you deploy AI agent infrastructure directly into your own AWS, Azure, GCP, Oracle, CoreWeave, or on-premises environment while using the same platform experience. > Each AI agent runs inside an isolated sandbox that can start in milliseconds, execute code securely, access only the resources it's been granted, and automatically terminate when work is complete. GPU workloads, sandbox environments, APIs, databases, object storage, and inference services all run within the same control plane, allowing AI agents to move seamlessly between reasoning and execution without stitching together multiple platforms. ### What Northflank provides for AI agents - [**MicroVM-isolated sandboxes**](https://northflank.com/product/sandboxes) using Firecracker and Kata Containers, with gVisor also available depending on workload requirements. - [**GPU workloads**](https://northflank.com/product/gpu-paas) across H100, H200, A100, L4, L40S, B200, GB300, and more, allowing agents to combine CPU execution with GPU-accelerated inference and processing. - [**Secrets management**](https://northflank.com/docs/v1/application/secure/security-on-northflank#secret-management) that securely injects credentials into each session without persisting them after execution completes. - [**Built-in networking and service discovery**](https://northflank.com/docs/v1/application/network/networking-on-northflank) so agents can securely communicate with databases, APIs, MCP servers, and internal services. - [**RBAC**](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [**SSO**](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication), and [**audit logging**](https://northflank.com/docs/v1/application/observe/audit-logs) for enterprise governance across users, projects, and environments. - [**Integrated databases, object storage, and persistent volumes**](https://northflank.com/docs/v1/application/databases-and-persistence/stateful-workloads-on-northflank) so agents can store state, retrieve data, and access files without leaving the platform. - [**BYOC**](https://northflank.com/product/bring-your-own-cloud) and [**forward-deployed control planes**](https://northflank.com/enterprise) for organisations that need AI agents to run entirely inside their own cloud account or private infrastructure. - [**Northflank Skills**](https://github.com/northflank/skills) for Claude Code, Codex, Cursor, Gemini CLI, and other AI coding assistants, allowing agents to provision and manage infrastructure directly through natural language. Northflank has demonstrated the scale required for production AI agent platforms. In the [ComputeSDK 2026 Scale Invitational](https://platform.computesdk.com/scale-invitational/northflank), Northflank launched 100,000 concurrent sandbox environments from a cold start in just 24 seconds with zero failures, demonstrating that AI agent infrastructure can scale rapidly without sacrificing startup performance. For teams building large-scale AI agent platforms, that means execution environments can start quickly, scale elastically, and automatically clean up after every session without manual infrastructure management. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) to see how Northflank handles sandboxes at scale for your team. ## FAQ: Computers for AI agents ### Can AI agents run on a laptop? Yes. Laptops are great for development and testing. Production AI agents typically run in cloud execution environments that provide better security, scalability, and reliability. ### Do AI agents need GPUs? Not always. Most agents use CPUs for execution, while GPUs are used for AI inference, image processing, or other accelerated workloads. ### What's the difference between a container and a sandbox? Containers share the host kernel, while sandboxes provide stronger isolation for each agent session. This makes sandboxes better suited for executing AI-generated or untrusted code. ### Why do AI agents need isolated execution environments? Isolation prevents one agent from affecting another, protects sensitive credentials, and reduces the impact of compromised code or prompt injection attacks. ### What is a microVM? A microVM is a lightweight virtual machine that provides stronger isolation than containers while maintaining fast startup times. Technologies like Firecracker and Kata Containers are commonly used for AI agent sandboxes. ### What's the best computer for production AI agents? Most organisations use cloud sandbox environments because they provide isolation, automatic scaling, secure networking, and built-in governance. Platforms like Northflank combine these capabilities with GPU workloads, databases, and BYOC in a single platform. ## Conclusion A computer for an AI agent is the execution environment where it runs code, accesses data, calls tools, and interacts with external systems. While local machines are enough for development, production AI agents typically run inside isolated cloud sandbox environments. Modern AI agent platforms need more than compute. They require isolation, networking, secrets management, observability, autoscaling, GPU support, and governance to run securely at scale. Northflank brings all of these together in a single platform, allowing teams to deploy, run, and scale AI agents without managing the underlying infrastructure. [Get started on Northflank (self-serve)](https://app.northflank.com/signup) or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ## Related articles - [**Best enterprise AI sandbox platforms**](https://northflank.com/blog/best-enterprise-ai-sandbox-platforms) - [**Top GPU sandboxes for AI agents**](https://northflank.com/blog/top-gpu-sandboxes-for-ai-agents) - [**How to secure AI agents in the cloud**](https://northflank.com/blog/how-to-secure-ai-agents-in-the-cloud) - [**What is a sandbox?**](https://northflank.com/blog/what-is-a-sandbox-and-isolation-technologies)

Best NVIDIA L4 GPU cloud providers for AI inference in 2026

2026-07-30T16:46:00.000Z

Renting an NVIDIA L4 is only one part of deploying production inference. This article compares five providers across application platforms, GCP and AWS infrastructure, serverless functions, and persistent GPU Pods, focusing on pricing, infrastructure control, scaling, and production workload fit. ## TL;DR: Best NVIDIA L4 GPU cloud providers - **Northflank** suits engineers, startups, and enterprises running L4 inference alongside APIs, workers, jobs, databases, CI/CD, autoscaling, and observability, with managed cloud, self-serve BYOC, or on-premises and bare-metal BYOK deployment. - **Google Cloud Compute Engine** suits GCP-native organizations that want G2 VM choices, GKE integration, and direct control of Google Cloud infrastructure. - **Amazon EC2 G6** suits AWS-native organizations that want L4 instances within existing IAM, VPC, EC2 automation, and cloud-purchasing workflows. - **Modal** suits bursty Python inference and batch workloads that benefit from a function abstraction and separately metered, per-second resources. - **Runpod** suits teams that need persistent L4 Pods, custom Docker images, and Pod-level environment control. Production AI teams need to connect L4 inference to APIs, workers, databases, storage, networking, deployment workflows, and monitoring. Northflank runs these components together on [Northflank Cloud](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-on-northflank-cloud) or through [self-serve BYOC](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud), with enterprise controls for infrastructure ownership, IAM, data residency, and auditability. [Request NVIDIA GPU capacity](https://northflank.com/request/gpu), [get started self-serve](https://app.northflank.com/signup), or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30). ## What should you look for in an NVIDIA L4 cloud provider? The GPU model may be the same, but the infrastructure and pricing around it can change the operational result. - **Workload fit:** Match the L4 to inference, image generation, video, rendering, or parameter-efficient fine-tuning. - **Total cost:** Compare GPU, CPU, memory, storage, networking, utilization, and pricing multipliers. - **Operating model:** Decide whether you need direct infrastructure control, serverless execution, persistent Pods, or a platform that also manages the surrounding application. ## Is the NVIDIA L4 the right GPU for AI inference? The NVIDIA L4 is an Ada Lovelace data-center GPU with 24 GB of GDDR6 memory, 300 GB/s memory bandwidth, two NVENC engines, four NVDEC engines, and a 72 W maximum TDP. That profile makes it a practical option for small and medium model inference, image generation, video processing, rendering, and selected parameter-efficient fine-tuning workloads. Whether a model fits depends on its precision, quantization, context length, batch size, and runtime overhead. Larger models or higher-throughput deployments may require an accelerator with more memory. For a closer look at specifications and provider rates, see [how much an NVIDIA L4 GPU costs](https://northflank.com/blog/how-much-does-an-nvidia-l4-gpu-cost). ## NVIDIA L4 cloud providers compared The table summarizes the operational differences that determine which provider fits a workload. All prices are as at 30 July 2026. | Provider | Best for | Deployment | L4 GPU pricing | Pricing scope | | --- | --- | --- | --- | --- | | Northflank | Running production AI applications with GPU, application infrastructure, and operational controls together | Managed cloud, self-serve BYOC, or on-premises and bare-metal clusters via BYOK | L4 24 GB: $0.80/hr; A100 40 GB: $1.42/hr; A100 80 GB: $1.76/hr; H100 80 GB: $2.74/hr; RTX PRO 6000 96 GB: $3.00/hr; and more | GPU rates include attached CPU and RAM | | Google Cloud Compute Engine | Running GCP-native inference on configurable infrastructure | G2 VMs or GKE nodes | `g2-standard-4`, 1x L4 24 GB: $0.706832276/hr on demand in `us-central1` (Iowa) | VM includes 4 vCPUs and 16 GiB RAM; storage and networking are separate | | Amazon EC2 G6 | Running AWS-native inference within existing AWS infrastructure | G6 instances with 1 to 8 L4 GPUs | `g6.xlarge`, 1× NVIDIA L4 24 GB: $0.8048/hr for On-Demand Linux in `us-east-1` (N. Virginia) | Instance includes 4 vCPUs, 16 GiB RAM, and 250 GB local NVMe; additional AWS charges may apply | | Modal | Running bursty Python functions and jobs | Serverless functions and containers | NVIDIA L4 24 GB: $0.80/GPU-hr | GPU, CPU, memory, and volumes are billed separately | | Runpod | Running lower-cost persistent GPU Pods with custom images | GPU Pods | L4 24 GB Pods from $0.39/hr on Secure Cloud or $0.44/hr on Community Cloud | Listed Pod configuration includes 12 vCPUs and 50 GB RAM; storage is billed separately | These rates are not like for like. Included CPU, RAM, storage, networking, operating-system costs, and platform services differ. ## What are the best NVIDIA L4 GPU cloud providers for AI inference? The five providers below address different parts of the L4 deployment problem, from complete production applications to direct VM and container access. ### 1. Northflank Northflank suits teams running NVIDIA L4 workloads as part of a complete production application rather than as isolated GPU compute. It brings GPU services, APIs, workers, jobs, databases, CI/CD, autoscaling, and observability into one workflow across Northflank Cloud, self-serve BYOC, or BYOK infrastructure. Enterprises gain infrastructure control and governance, while startups and smaller engineering teams can deploy without building their own platform layer. - **GPU choice and pricing:** The [Northflank GPU platform](https://northflank.com/product/gpu-paas) supports L4 24 GB at $0.80/hour, A100 40 GB at $1.42/hour, A100 80 GB at $1.76/hour, H100 80 GB at $2.74/hour, RTX PRO 6000 96 GB at $3.00/hour, and more. GPU rates bundle the accelerator with its attached CPU and RAM and are metered per second. - **Additional resource pricing:** For CPU-only workloads, Northflank lists CPU at $0.01667/vCPU/hour and memory at $0.00833/GB/hour. SSD storage is $0.15/GB/month and network egress is $0.06/GB. Check the [pricing page](https://northflank.com/pricing) and calculator for current rates and a workload estimate. - **Complete application platform:** GPU inference can run beside APIs, workers, scheduled jobs, managed databases, persistent storage, networking, secrets, CI/CD, autoscaling, and observability. This reduces the number of separate systems a team must connect and operate. - **Infrastructure choice:** Teams can [deploy GPUs on Northflank's managed cloud](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-on-northflank-cloud), [deploy GPUs in their own cloud](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud), or bring on-premises and bare-metal Kubernetes clusters through BYOK. BYOC and BYOK retain control over infrastructure, regional placement, networking, IAM, data residency, and cloud billing while Northflank provides a consistent operational workflow. - **Governance and integration:** Enterprise capabilities include SSO with SAML or OIDC, audit logs, global backups and HA/DR, secure runtime and on-premises deployment options, plus integrations for an existing registry, Vault, and DNS. - **Self-serve access:** Startups and smaller engineering teams can deploy the same GPU, API, job, database, and delivery stack without first building an internal platform. - **GPU operations:** Use the [GPU documentation](https://northflank.com/docs/v1/application/gpu-workloads/gpus-on-northflank) to deploy GPU-backed services and jobs. Use the [configuration and optimisation guide](https://northflank.com/docs/v1/application/gpu-workloads/configure-and-optimise-workloads-for-gpus) to configure scaling, health checks, networking ports, startup commands, and persistent volumes for production operation. The distinction between these providers is the scope each one manages. Google Cloud and AWS provide native infrastructure that the customer's engineering team operates. Modal manages a serverless function abstraction, while Runpod provides GPU Pods and serverless workers. Northflank manages the GPU workload and its surrounding application services on Northflank Cloud, in the customer's cloud through BYOC, or on existing on-premises and bare-metal Kubernetes through BYOK. The Weights engineering team used Northflank to operate a multi-cloud AI platform across nine clusters, more than 40 microservices, and over 250 concurrent GPUs without a dedicated DevOps team. The [Weights case study](https://northflank.com/blog/weights-uses-northflank-to-scale-to-millions-of-users-without-a-devops-team-ai-k8s) is not specific to the L4, but it demonstrates how Northflank can coordinate GPU workloads and application infrastructure at production scale. [Request NVIDIA L4 or other GPU capacity](https://northflank.com/request/gpu) for production, volume, or reservation requirements. You can also [get started self-serve](https://app.northflank.com/signup), or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) for architecture, security, compliance, data residency, or migration requirements. ### 2. Google Cloud Compute Engine Google Cloud Compute Engine fits teams already operating on GCP that want direct control over L4-backed G2 VMs or GKE node pools. - **Infrastructure:** G2 accelerator-optimized machine types attach NVIDIA L4 GPUs in different CPU, memory, and GPU configurations, with access through VMs or GKE node pools. - **Machine choice:** G2 configurations range from one to eight L4 GPUs, so teams can choose CPU, memory, and accelerator capacity around the workload. - **Pricing:** In Iowa, `g2-standard-4` with one L4, 4 vCPUs, and 16 GiB memory costs $0.706832276/hour on demand, $0.445304335/hour with a one-year commitment, or $0.318074524/hour with a three-year commitment. Persistent storage and networking are separate, and regional prices vary. - **Purchasing options:** Google Cloud supports on-demand, Spot, reservation, and committed-use models for teams balancing flexibility, capacity planning, and longer-term cost. - **Regional deployment:** G2 availability is zone-specific, allowing teams to select a supported location that fits latency and data-location requirements. Choose Google Cloud Compute Engine when your team wants direct control over G2 VMs or GKE node pools and already has the expertise to operate the surrounding GCP infrastructure. You retain native control, but your team remains responsible for orchestration and day-to-day operations around the GPU workload. If you need to keep workloads, data, networking, IAM, and cloud billing within your GCP account without taking on the operational overhead of building and maintaining the surrounding application platform, [Northflank BYOC for GCP](https://northflank.com/cloud/gcp) provides a managed layer for orchestration, deployment, scaling, CI/CD, observability, databases, and GPU workloads. This gives enterprises greater control over data residency, security, and existing GCP commitments while reducing the infrastructure their platform teams must operate directly. ### 3. Amazon EC2 G6 Amazon EC2 G6 fits teams standardized on AWS that want NVIDIA L4 capacity inside existing EC2 and VPC workflows. - **Infrastructure:** G6 configurations provide from one to eight NVIDIA L4 GPUs, each with 24 GB of memory, inside EC2 and VPC workflows. - **Instance choice:** Single-GPU G6 sizes offer different vCPU and memory ratios, multi-GPU sizes provide four or eight L4 GPUs, and G6f offers fractional GPU profiles for smaller workloads. - **Pricing:** In US East (N. Virginia), Linux `g6.xlarge` costs $0.8048 per On-Demand instance-hour and includes one L4, 4 vCPUs, 16 GiB memory, and 250 GB local NVMe. The rate comes from the AWS Price List accessed on 30 July 2026. Linux usage is billed per second with a 60-second minimum. EBS, public IPv4, and applicable data transfer are separate. Spot and Savings Plan prices vary. - **Purchasing options:** Teams can use On-Demand Instances for flexible capacity, Spot Instances for interruptible workloads, or Savings Plans for steadier usage. - **AWS integration:** G6 instances fit existing IAM, VPC, EC2 automation, monitoring, and procurement workflows. Choose Amazon EC2 G6 when your team wants direct control over L4 instances within existing AWS identity, VPC, automation, governance, and purchasing workflows. Your team remains responsible for orchestrating and operating the application infrastructure around those instances. If you need to keep workloads, data, networking, IAM, and cloud billing within your AWS account without building and maintaining the surrounding application platform, [Northflank BYOC for AWS](https://northflank.com/cloud/aws) provides a managed layer for orchestration, deployment, scaling, CI/CD, observability, databases, and GPU workloads. This helps enterprises retain control over data residency, security, and existing AWS commitments while reducing the infrastructure their platform teams operate directly. ### 4. Modal Modal fits Python teams that want L4-backed functions and jobs without managing VMs or Kubernetes. - **Workload model:** Developers package inference endpoints, scheduled work, and batch processing as functions or containerized jobs. - **Pricing:** Modal lists the NVIDIA L4 24 GB at $0.80 per GPU-hour. CPU costs $0.0473 per physical core-hour, memory costs $0.0080 per GiB-hour, and Volumes cost $0.09/GiB/month. These are base rates; explicit region selection costs 1.5–1.75 times the base price, while non-preemptible execution costs three times the base price. - **Scaling:** The serverless execution model scales containers with demand and can release resources when work completes, which suits intermittent traffic and short jobs. - **Multi-GPU support:** L4 containers can request up to eight GPUs on the same physical machine, although requests above two GPUs can take longer to fulfill. - **Persistence:** Modal Volumes provide durable storage for model weights, datasets, checkpoints, and generated outputs across function runs. Choose it for intermittent inference, experiments, and batch jobs that fit a function abstraction. ### 5. Runpod Runpod fits teams prioritizing a low published L4 Pod rate and direct control of a container image. - **Pod configuration:** The Runpod configuration as of 30 July 2026 combined one L4 with 12 vCPUs and 50 GB RAM. Available host configurations may vary, and Pods support custom Docker images. - **Cloud options:** Secure Cloud and Community Cloud provide separate infrastructure pools and L4 rates, letting teams choose according to production, security, and cost requirements. - **Pricing:** Runpod lists L4 Pods from $0.39/hour on Secure Cloud and $0.44/hour on Community Cloud with per-second billing. Container disk costs $0.10/GB/month. Volume disk costs $0.10/GB/month while running and $0.20/GB/month while idle. - **Serverless option:** Runpod Serverless costs $0.69/hour for a mixed 24 GB GPU pool that can supply an L4, A5000, 3090, or 24 GB MIG allocation. It is not an L4-specific rate, so teams that require an exact L4 can use an L4 Pod, subject to availability. - **Environment control:** GPU Pods support custom Docker images, allowing teams to choose their frameworks, libraries, and runtime dependencies. Choose it when a lower-cost persistent Pod and custom image are the main requirements. If you are also comparing Runpod’s GPU Pods and Serverless workers with Modal’s function-based model, see [Runpod vs Modal](https://northflank.com/blog/runpod-vs-modal) for a closer look at their pricing, scaling, deployment workflows, and infrastructure trade-offs. ## How should you choose an NVIDIA L4 cloud provider? Match the provider to the application's operating model rather than one hourly GPU figure. - Choose **Northflank** when engineers want to deploy an L4-backed service or job without assembling the surrounding platform themselves, when a startup needs GPU and application infrastructure in one workflow, or when an enterprise needs BYOC, BYOK, data residency, access controls, auditability, and consistent multi-cloud operations. - Choose **Google Cloud Compute Engine** when GCP-native VM or GKE control is the primary requirement. - Choose **Amazon EC2 G6** when AWS IAM, VPC, EC2 automation, and purchasing models determine the architecture. - Choose **Modal** when short, bursty Python functions and jobs benefit from per-second serverless execution. - Choose **Runpod** when you need a persistent GPU Pod, a custom container image, and Pod-level environment control. For steady workloads, calculate monthly infrastructure and engineering overhead. For variable workloads, test cold starts, scaling, availability, and the actual execution window. ## Frequently asked questions about NVIDIA L4 cloud providers ### Which NVIDIA L4 cloud provider is cheapest? Runpod Secure Cloud has the lowest starting NVIDIA L4 24 GB Pod rate in this comparison at $0.39/hour, excluding persistent storage. Northflank costs $0.80/hour and bundles the NVIDIA L4 24 GB with its attached CPU and RAM, while also supporting the surrounding application on the same platform. Compare total infrastructure and engineering costs rather than the GPU rate alone. ### Can enterprises run NVIDIA L4 workloads in their own cloud or VPC? Yes, when the deployment model supports customer-controlled infrastructure. Northflank's self-serve [BYOC](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud) lets teams deploy GPU workloads into their cloud account while retaining control over infrastructure, regions, networking, IAM, data residency, and cloud billing. BYOK extends the same platform workflow to existing on-premises and bare-metal Kubernetes clusters. ### Is the NVIDIA L4 good for AI inference? Yes, when the model and runtime fit within its 24 GB memory. Its Ada Lovelace architecture and media engines suit inference, image generation, and video processing. Engineers can run L4-backed services and jobs on Northflank, then keep the same deployment workflow if a workload later moves to an A100, H100, H200, B200, or another supported GPU with more memory or a different performance profile. ### Should startups use an application platform or a raw GPU provider? A raw GPU provider can fit a narrow service or a team comfortable assembling its own infrastructure. An application platform is useful when the startup also needs APIs, workers, databases, CI/CD, secrets, networking, and observability. Northflank offers self-serve [managed-cloud](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-on-northflank-cloud) and [BYOC](https://northflank.com/docs/v1/application/gpu-workloads/deploy-gpus-in-your-own-cloud) paths for this broader requirement. ### Should you choose serverless or a dedicated NVIDIA L4 instance? Serverless execution fits intermittent, request-driven work that can tolerate the platform's startup and lifecycle behavior. Persistent instances or Pods fit steady services and workloads that need direct environment control. Northflank supports continuously running services and jobs, Modal uses a serverless function model, and Runpod provides persistent Pods. ## Related articles to NVIDIA L4 GPUs - [How much does an NVIDIA L4 GPU cost?](https://northflank.com/blog/how-much-does-an-nvidia-l4-gpu-cost): Compare L4 specifications, pricing models, and Northflank deployment options. - [Top GPU sandboxes for AI agents](https://northflank.com/blog/top-gpu-sandboxes-for-ai-agents): Compare isolated GPU execution platforms for agent workloads that need direct accelerator access. - [GPU workloads on Northflank](https://northflank.com/gpu): Review supported GPUs and deployment paths for inference, training, and compute-intensive workloads. - [How much does an NVIDIA A100 GPU cost?](https://northflank.com/blog/nvidia-a100-gpu-cost): Compare cloud pricing for the 40 GB and 80 GB A100 variants. - [How much does an NVIDIA H100 GPU cost?](https://northflank.com/blog/how-much-does-an-nvidia-h100-gpu-cost): Review H100 pricing for higher-throughput inference and training. - [How much does an NVIDIA B200 GPU cost?](https://northflank.com/blog/how-much-does-an-nvidia-b200-gpu-cost): Understand pricing for NVIDIA Blackwell infrastructure.

Best PaaS for enterprises in 2026

2026-07-29T16:42:00.000Z

Choosing an enterprise PaaS means deciding how much infrastructure your teams should operate and control. It should speed up delivery while meeting identity, networking, residency, cost, and infrastructure requirements. This guide compares four operating models: multi-infrastructure PaaS, enterprise Kubernetes, Azure-native web PaaS, and Google serverless containers. These editorial assessments use the criteria below, so “best” means the best fit for your enterprise requirements and operating model. ## TL;DR: Best PaaS for enterprises Match each platform to your primary requirement. - **Northflank** is the best overall choice for enterprises that want one PaaS across multiple clouds, customer-owned infrastructure, and Kubernetes without being locked into one hyperscaler. It combines application delivery, databases, jobs, CPU and GPU workloads, release workflows, preview environments, and enterprise governance on one platform. - **Red Hat OpenShift** suits organisations standardising on Kubernetes across hybrid or multi-cloud infrastructure and prepared to operate a configurable platform. - **Microsoft Azure App Service** suits web applications and APIs in enterprises already centred on Azure networking and governance. - **Google Cloud Run** suits autoscaling container services, finite jobs, and continuous worker pools within Google Cloud. If you need faster delivery without tying your application platform to one hyperscaler, [Northflank](https://northflank.com/) gives your enterprise one PaaS across [managed cloud](https://northflank.com/features/managed-cloud), customer-owned cloud accounts and VPCs through [self-service BYOC](https://northflank.com/features/bring-your-own-cloud), and existing Kubernetes infrastructure through [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements). Run [services, jobs, databases, and storage](https://northflank.com/features/application-layer), manage deployments through the [release layer](https://northflank.com/features/release-layer), and support both CPU and [GPU workloads](https://northflank.com/product/gpu-paas) through consistent deployment and governance workflows. [SSO](https://northflank.com/docs/v1/application/secure/single-sign-on-multi-factor-authentication), [SCIM](https://northflank.com/security), [RBAC](https://northflank.com/docs/v1/application/secure/use-role-based-access-control), [audit logs](https://northflank.com/docs/v1/application/observe/audit-logs), [private networking](https://northflank.com/docs/v1/application/network/networking-on-northflank#private-networking), and [controlled releases](https://northflank.com/features/release-layer) help you apply company policies across environments. [Northflank is SOC 2 Type 2 and HIPAA compliant](https://northflank.com/security), with BAAs supported under Enterprise contracts. [**Get started with Northflank (self-serve)**](https://app.northflank.com/signup), or [**book a demo**](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, networking, or migration requirements. ## What makes a PaaS enterprise-ready? Evaluate each platform against the controls and operating outcomes your organisation needs. - **Identity and governance:** Check SSO, provisioning, RBAC, workload identity, and audit-log scope. - **Deployment and data control:** Decide whether workloads can use managed infrastructure or must run in your account, VPC, region, data centre, or cluster. - **Private networking:** Check private ingress, controlled egress, static outbound addresses, virtual-network connectivity, and access to on-premises systems. - **Workload breadth:** Map your web services, workers, jobs, databases, queues, persistent storage, GPUs, and multi-environment release requirements. - **Portability and operating burden:** Decide what your platform team should own and what the provider should manage. - **Cost governance:** Model platform fees, support, infrastructure, idle capacity, and internal engineering effort. - **Developer experience:** Test delivery, templates, preview environments, APIs, approvals, and promotion workflows with a real application. ## Best enterprise PaaS platforms at a glance Compare each platform's deployment, governance, networking, and billing model. | Platform | Best for | Deployment model | Governance | Private networking | Pricing model | | --- | --- | --- | --- | --- | --- | | Northflank | Enterprises running mixed workloads across managed cloud, customer-owned infrastructure, and Kubernetes through one governed PaaS | Managed cloud, BYOC across major clouds, or BYOK on supported cloud, bare-metal, and on-premises Kubernetes infrastructure | RBAC; Enterprise adds SSO, SCIM, and expanded auditing | Private services, network policies, egress controls, and customer VPCs | Usage-based self-service; annual Enterprise platform fee with PaaS and BYOC usage discounts at eligible spend thresholds | | Red Hat OpenShift | Kubernetes standardisation and hybrid-cloud control | Self-managed or managed across major clouds | Kubernetes RBAC, namespaces, identity integration, and API auditing | Kubernetes and cloud-native network controls | Subscription or managed-service pricing plus infrastructure | | Microsoft Azure App Service | Web apps and APIs within Azure | Microsoft-managed, with dedicated and isolated plans | Uses the wider Azure identity and governance model | Private endpoints for ingress and VNet integration for egress | App Service capacity plus related Azure services | | Google Cloud Run | Container services, jobs, and workers within Google Cloud | Fully managed regional service | Google Cloud IAM, service identities, and organisation controls | VPC routing, firewall rules, and service perimeters | Consumption-based resource and request billing | **Note**: Other platforms, including Railway, Render, Vercel, and Netlify, can support enterprise deployments, but their standard deployment models run application workloads on infrastructure managed by the platform provider. Some offer private networking, dedicated compute, or secure connections to resources in your VPC, but they do not primarily deploy the application platform and its workloads into your enterprise’s cloud account, on-premises environment, or existing Kubernetes cluster. Because this comparison prioritises infrastructure ownership, deployment control, data boundaries, and portability across enterprise environments, these platforms are not included. ## What are the best PaaS platforms for enterprises? The following sections show where each platform fits your architecture and operating model. ### 1. Northflank Choose Northflank when you want a unified application platform across multiple clouds, customer-owned infrastructure, and Kubernetes without making developers work directly with each provider’s infrastructure services. - **One internal developer platform:** Northflank connects its [core platform](https://northflank.com/features/platform), [infrastructure layer](https://northflank.com/features/infrastructure-layer), [application layer](https://northflank.com/features/application-layer), and [release layer](https://northflank.com/features/release-layer) in one [internal developer platform](https://northflank.com/product/idp). Your teams can use the UI, API, CLI, GitOps, templates, logs, metrics, secrets, and workflows without assembling a separate platform around Kubernetes. See the [Northflank documentation](https://northflank.com/docs/v1/application) for implementation guidance. - **Infrastructure and Kubernetes control:** Use [Northflank Cloud](https://northflank.com/features/managed-cloud), self-serve [BYOC](https://northflank.com/features/bring-your-own-cloud), or [BYOK](https://northflank.com/docs/v1/application/bring-your-own-cloud/byoc-and-byok-requirements) with the same workflow. The [Kubernetes application platform](https://northflank.com/product/app-platform) gives developers higher-level services, jobs, and database primitives while your platform team retains cloud, cluster, VPC, and data-residency control. - **Customer VPC deployments:** If you sell software that customers require inside their own infrastructure, [customer VPC deployments](https://northflank.com/product/customer-vpc-deployments) let you define the application once and manage delivery across customer-owned AWS, Google Cloud, Azure, or on-premises environments. - **Deployments and release control:** [Deployments](https://northflank.com/product/deployments) support Git-based builds, Dockerfiles, buildpacks, services, jobs, and databases. The [release layer](https://northflank.com/features/release-layer) adds promotion workflows, approvals, migrations, backups, rollbacks, and audit history across environments. - **Preview environments:** Automatically create full-stack preview environments for pull requests, including services, databases, and jobs, then remove them when branches close. This gives reviewers a production-shaped environment before changes progress. - **CPU, GPU, and isolated workloads:** Run APIs, workers, scheduled jobs, databases, storage, and both CPU and [GPU workloads](https://northflank.com/product/gpu-paas). [Northflank Sandboxes](https://northflank.com/product/sandboxes) add microVM or gVisor-based isolation for untrusted code, agent tasks, and multi-tenant execution. - **Enterprise governance and compliance:** [Northflank Enterprise](https://northflank.com/enterprise) includes SAML/OIDC SSO, SCIM, RBAC, workload identities, policy enforcement, SIEM audit-log export, global secrets, OpenTofu-enabled templates, and organisation-level APIs. [Northflank is SOC 2 Type 2 and HIPAA compliant](https://northflank.com/security), with BAAs supported under Enterprise contracts. - **Support and controlled deployment:** Enterprise options include named engineers, 24/7 support, custom SLAs, architecture reviews, migration planning, disaster-recovery configurations, and forward-deployed logging. BYOK, customer-hosted control planes, and air-gapped deployment support stricter infrastructure boundaries. Some capabilities require specific spend thresholds or arrangements; [Enterprise documentation](https://northflank.com/docs/v1/application/enterprise) provides the current scope. - **Enterprise pricing and discounts:** Northflank remains available through usage-based self-service pricing. [Northflank Enterprise](https://northflank.com/docs/v1/application/enterprise) uses an annual platform fee, with PaaS and BYOC usage discounts available at eligible spend thresholds. Some Enterprise capabilities and commercial terms depend on your organisation’s requirements and agreement. Upwork’s Lifted [migrated 13 development and production services from Google Cloud to AWS in four hours with Northflank](https://northflank.com/blog/upwork-lifted-runs-production-workloads-inside-their-own-vpc-with-northflank). Northflank BYOC preserved self-service deployments and preview environments while giving its platform and security teams control over infrastructure, compliance, and isolation inside its AWS VPC. [**Get started with Northflank (self-serve)**](https://app.northflank.com/signup), or [**book a demo**](https://cal.com/team/northflank/northflank-demo?duration=30) to discuss architecture, security, compliance, networking, customer VPC deployment, or migration requirements. ### 2. Red Hat OpenShift Choose Red Hat OpenShift if Kubernetes is your strategic infrastructure layer and your platform team can manage the flexibility that comes with it. - **Deployment model:** Use self-managed editions or managed services across major clouds, depending on how much cluster responsibility you want to retain. - **Developer platform:** OpenShift Container Platform provides a developer console and integrates with Red Hat Serverless, Service Mesh, Pipelines, and GitOps capabilities. - **Governance:** Kubernetes RBAC and namespaces support multitenancy, while configurable API audit profiles control how much request detail is recorded. - **Operating responsibility:** You still need clear ownership for cluster capacity, security policy, upgrades, and platform add-ons, even when a managed service moves some responsibilities to Red Hat and the cloud provider. ### 3. Microsoft Azure App Service Choose Microsoft Azure App Service if most of your target workloads are web applications or APIs and Azure already defines your identity, networking, monitoring, and procurement model. - **Application model:** Host Windows or Linux web applications and APIs, using code or containers, within a managed Azure service. - **Private ingress:** Private endpoints provide inbound access through Azure Private Link on eligible Basic, Standard, PremiumV2, PremiumV3, PremiumV4, IsolatedV2, and Functions Premium plans. - **Outbound connectivity:** VNet integration lets an app reach resources in an Azure virtual network or a connected on-premises environment. - **Network planning:** You must disable public access separately when an application should have no public exposure. Plan private ingress, outbound routing, DNS, subnets, and plan eligibility together rather than treating VNet integration as one control for all traffic. ### 4. Google Cloud Run Choose Google Cloud Run if your container services, jobs, and workers fit Google Cloud's managed execution and governance model. - **Workload model:** Services autoscale in response to requests, jobs execute finite tasks, and worker pools provide continuous processing. Worker-pool instance scaling is manual by default, with external-metrics autoscaling available through CREMA. - **Identity and access:** IAM controls management and invocation, while dedicated service accounts give workloads scoped identities. - **Private connectivity:** Direct VPC egress or Serverless VPC Access connects workloads to VPC resources, with firewall rules and compatible VPC Service Controls configurations adding policy boundaries. - **Multi-region availability:** Cloud Run service health can automate failover between separately deployed regional services connected through serverless network endpoint groups and a supported load balancer. ## How to choose an enterprise PaaS Use a production-shaped evaluation rather than selecting from feature pages. 1. **Set your deployment boundary:** Decide where workloads and data may run. 2. **Map your governance requirements:** Define identity, access, audit, secrets, policy, and retention controls. 3. **Classify your workload portfolio:** Include services, jobs, stateful systems, databases, and GPUs. 4. **Model total platform cost:** Include infrastructure, platform fees, support, and internal staffing. 5. **Test a representative application:** Validate networking, deployment, rollback, scaling, backup recovery, and incident access. ## Which enterprise PaaS should you choose? Choose according to your infrastructure strategy, workload requirements, and the responsibilities your platform team wants to retain. - **Choose Northflank** if you want one governed PaaS across managed cloud, customer-owned cloud accounts, and supported Kubernetes infrastructure. It suits enterprises running services, jobs, databases, storage, and CPU or GPU workloads that want to reduce vendor lock-in, avoid dependence on a single hyperscaler, and preserve infrastructure portability. - **Choose Red Hat OpenShift** if Kubernetes is your strategic infrastructure layer and your platform team wants direct control over clusters, policies, extensions, and hybrid-cloud operations. - **Choose Microsoft Azure App Service** if your applications are primarily web apps and APIs and your organisation already uses Azure for identity, networking, monitoring, and procurement. - **Choose Google Cloud Run** if you need autoscaling container services, finite jobs, and continuous workers within Google Cloud’s IAM, networking, and governance model. Northflank is the best overall choice when you need broad workload support and infrastructure flexibility without requiring developers to operate Kubernetes directly. [**Start deploying on Northflank (self-serve)**](https://app.northflank.com/signup), or [book a demo](https://cal.com/team/northflank/northflank-demo?duration=30) **to discuss architecture, security, compliance, networking, migration, or procurement requirements**. ## Frequently asked questions about enterprise PaaS These answers cover common enterprise architecture, governance, and deployment questions. ### What is an enterprise PaaS? An enterprise PaaS gives your developers managed build, deployment, and runtime workflows while adding central identity, RBAC, auditing, private networking, support commitments, and cost controls. Northflank extends this model across services, jobs, databases, delivery workflows, and managed or customer-owned infrastructure. ### Can you run an enterprise PaaS in your own cloud account? That depends on the platform. With [Northflank BYOC](https://northflank.com/features/bring-your-own-cloud), the workload data plane runs in your cloud account and VPC while Northflank manages the platform layer. This helps when you need control over data residency, networking, cloud commitments, or specialised compute. ### Is Northflank suitable for regulated workloads? [Northflank is SOC 2 Type 2 and HIPAA compliant](https://northflank.com/security), and BAAs are supported under Enterprise contracts. You still need to map your workload, configuration, data flow, deployment region, and shared responsibilities to the applicable control set rather than relying on provider compliance alone. ### How is a PaaS different from Kubernetes? Kubernetes orchestrates containers. A PaaS adds developer workflows for builds, deployments, environments, secrets, domains, observability, and application lifecycle. Northflank can run over managed Kubernetes through BYOC or supported existing clusters through BYOK, so your developers do not need to operate Kubernetes directly. ## Related articles to enterprise PaaS Use these Northflank guides to investigate Kubernetes, internal platforms, BYOC, and migrations. - [Kubernetes PaaS: should you build your own or use a platform?](https://northflank.com/blog/kubernetes-paas): Compare custom and existing platform approaches. - [How to build an internal developer platform and why you might not want to](https://northflank.com/blog/how-to-build-an-internal-developer-platform): Understand IDP capabilities and ownership. - [What is BYOC in cloud computing?](https://northflank.com/blog/what-is-byoc-in-cloud-computing): Understand BYOC ownership, compliance, and cost. - [Bring your own cloud app hosting](https://northflank.com/blog/bring-your-own-cloud-app-hosting): Decide when customer-owned infrastructure fits. - [What is the closest alternative to Heroku Enterprise?](https://northflank.com/blog/what-is-the-closest-alternative-to-heroku-enterprise): Compare Heroku Enterprise with Northflank. - [What does an AI-powered secure SDLC look like?](https://northflank.com/blog/ai-powered-secure-sdlc): Govern AI-assisted software delivery.