Northflank runs AI workloads across managed and own clouds

Northflank supplies infrastructure for applications, AI workloads and coding agents. It combines container deployment with GPU execution, sandboxes and development environments that can run on Northflank’s managed cloud or infrastructure a customer controls. Its relevance to AI teams is the relationship between these pieces: the model, the application serving it and the agent writing its code can share an operating platform while remaining distinct workloads with different permissions and lifecycles.

01 / ProductA common control plane for several kinds of AI work

The Northflank overview presents production applications, agent sandboxes and cloud coding environments under one platform. That breadth matters because an AI feature rarely consists only of a model. It may need an API, data storage, background processing and a controlled place to run generated code. Northflank aims to operate those pieces through shared deployment and management interfaces.

The GPU product page describes container-based inference, training and notebook workloads on managed or customer-supplied capacity. A GPU is treated as a resource within the deployment platform, alongside CPU workloads. That can simplify the relationship between a model endpoint and the surrounding application, but the team still chooses an appropriate serving container, model and resource configuration.

The bring-your-own-cloud offer extends the platform into customer cloud accounts and Kubernetes environments. The appeal is consistent operating tooling while retaining a chosen infrastructure boundary. It is not a claim that moving workloads between providers is effortless in every application. Data gravity, region capacity, storage design and provider-specific integrations still shape the migration.

02 / AudienceTeams bridging model experiments and operated services

Northflank is relevant when a team wants more control than a single managed model API but less day-to-day cluster work than a fully bespoke platform. An AI product company might host its own inference container beside an application API. An engineering organisation might use cloud coding environments while retaining workloads inside its existing cloud account. The shared need is operational consistency across different execution patterns.

It can be excessive for a small application that only needs one external model call. Before adopting a platform, identify which responsibility it will remove: GPU scheduling, environment provisioning, deployment pipelines or agent workspace management. If none is currently a problem, a simpler service may be sufficient. The existence of many workload types is valuable only when they correspond to real operating needs.

Compare Modal when the natural unit of work is a Python function with explicit compute requirements. Compare E2B when programmable isolated machines for an agent are the primary requirement. Northflank’s distinguishing proposition is to place these AI execution needs alongside a wider application platform and a customer-cloud option. Evaluate the full service boundary rather than choosing on a single GPU price.

03 / WorkflowProposed workflow: a controlled coding environment

A proposed first evaluation is an agent that modifies a small internal application in a dedicated branch. Create a Cloud Harness, connect only the required repository and give the coding tool its supported authentication. The Cloud Harness quickstart describes repository selection, runtime variables, resources and workspace persistence. This is an evaluation design; no agent was deployed for this article.

Choose privacy and storage deliberately at creation. The quickstart says those choices cannot be changed later, and that disabling persistence means stops, restarts and redeployments erase workspace files and agent sign-ins. A disposable workspace may be suitable for a single test, while a continuing investigation needs retained files. Neither option replaces pushing important code and preserving evidence outside the lifetime of the environment.

Ask the agent to implement one change, run the relevant tests and produce a reviewable diff. Keep production credentials out of this first workspace. A successful code-generation task should end with a branch and evidence, not an automatic production release. Test interruption as well: pause the environment, resume it and confirm that the expected files remain available under the selected persistence policy.

For generated code supplied by application users, examine the separate sandbox product. Its documented runtime choices include microVM isolation and gVisor for GPU workloads. Those are implementation boundaries to evaluate, not a universal promise that arbitrary code is harmless. The application must still control network access, injected secrets, resource consumption and the lifecycle of files returned from each run.

04 / PricingManaged compute and BYOC fees need separate budgets

The live pricing page publishes usage-based compute and resource rates, billed by the second, with no seat fees. Managed cloud CPU and memory have separate units; storage and egress can add charges. That makes workload shape important. A process waiting on an external model may consume little CPU while still retaining memory and other allocated resources.

BYOC has its own platform fee basis, and the cloud provider’s infrastructure bill remains separate. The page also publishes a GPU management fee for customer-cloud capacity. Do not compare that fee directly with an all-in managed GPU rate and call it the cheaper machine. The comparison must include the customer’s GPU, networking, storage and any contractual commitments already in place.

For a pilot, estimate a complete environment: the harness or model service, application API, persistent storage and supporting database. Then measure active duration and the cost of idle resources. A programme that spins up several temporary workspaces can accumulate spend even if each one seems inexpensive. The free sandbox allowance is useful for exploration, but its limits do not establish a production capacity or support commitment.

05 / DistinctionsAgent workspaces and production have a shared operating context

The cloud-agent page describes coding tools running remotely with repositories and persistent workspaces. This can help teams whose long tasks should survive disconnecting a laptop. The platform’s role is to keep the environment available; the selected coding agent remains a separate tool with its own authentication, capabilities and usage terms. Northflank does not turn those tools into a single interchangeable model.

The same platform can host a model endpoint and the application that consumes it. This is useful when deployment failures cross boundaries: the API is healthy but its model service is unavailable, or a model restart changes the time required for a request. Shared visibility can reduce the number of systems an operator must inspect, while careful service-level checks still determine whether the feature works for a user.

BYOC also gives an organisation a way to use existing provider commitments and account controls. That is a concrete operating advantage when cloud ownership is already decided. However, standard container and Kubernetes interfaces do not remove every dependency on platform configuration. Keep the deployment definition, secrets model and recovery procedure understandable enough that another engineer can explain how the system would be restored.

06 / QuestionsResolve capacity, boundaries and persistence before expansion

GPU availability and model suitability remain workload-specific. A published hardware family or hourly price does not prove capacity in the required region at the required moment. Before committing a product launch, confirm the region, GPU shape and scaling limits for the chosen route. Measure model loading, queueing and response behaviour with representative inputs rather than quoting performance language from the product page.

Cloud Harness privacy choices affect how colleagues can access the environment. The quickstart distinguishes team-accessible harnesses from private ones and documents restrictions on connecting locally. Decide who needs to collaborate before creation. A private workspace is not necessarily the right option for an operational task that another engineer must recover, while broad team access may be inappropriate for credentials tied to one person.

Finally, distinguish durable artifacts from running processes. Files may persist under the selected policy even when a process has stopped, but the application still needs a defined restart procedure. Test the loss of an environment, not only a temporary disconnect. Preserve important results in their intended system of record and make cleanup part of the task, so temporary compute does not become an undocumented service.

07 / DecisionChoose the smallest complete operating example

Northflank is worth evaluating when AI compute, generated-code execution and ordinary application services need a coherent operating platform. Start with one environment that crosses a real boundary, such as an API calling a model service or a coding agent producing a tested branch. Compare the managed-cloud and BYOC routes using the same workload, and judge the result by operational clarity as well as the resource bill.