Provisioning Compute Nodes

Provision cloud compute resources on-demand through natural conversation with your AI assistant. No need to log into cloud consoles, manage SSH keys, or remember API commands.

Provisioning is generally available, from router 0.4.110

Every account may provision, on every plan including Free. There is no allowlist, no approval step and nothing to request. What bounds you is your plan's included compute and, on a paid plan, whether the credit balance behind it has anything left — a refusal quotes the numbers rather than telling you the feature is not yours.

Until this release access was granted per email domain, which admitted a handful of internal domains and no customer at all, while every plan's page sold an amount of included compute. If you tried provisioning before and were refused, try again.

What is Provisioning?

Provisioning in noBGP means creating new compute resources (VMs, instances, etc.) on cloud providers through your AI assistant. The entire process - from requesting a machine to having it ready for use - happens through conversation.

What Happens When You Provision

1. You describe what you need in natural language
2. Your AI assistant uses the provision_node MCP tool
3. noBGP creates the instance on a cloud provider (AWS, etc.)
4. The noBGP agent is automatically installed and configured
5. The node joins your specified network
6. You receive confirmation when it's ready to use

All of this typically takes 1-2 minutes.

Supported Providers

noBGP currently supports:

• AWS (Amazon Web Services) - Four fixed compute classes via managed containers (Amazon ECS)

Every provider runs the same image family, Ubuntu 24.04 LTS. See Compute Nodes.

How to Provision a Node

Basic Provisioning

The simplest way to provision a node:

Provision a new node in my default network

Your AI assistant will:

• Use the default class (small)
• Create the instance
• Configure it automatically
• Report when it's ready

Specifying Requirements

You can be more specific about what you need:

Provision a medium node in my production network

Or:

Create a node with 1 vCPU and 2 GB of RAM for my build jobs

The AI understands natural language and will pick the class that fits — there are four, and asking for a size between them gets you the nearest one that exists.

Example Conversation

You: I need a development server for testing Docker containers

AI: I'll provision a new node for you with Docker pre-installed.

    Creating instance...
    - Provider: AWS
    - Class: medium (1 vCPU / 2 GiB) — $0.06/hour
    - Network: default

    Installing noBGP agent and Docker...

    ✓ Node "dev-server-1" is now online!

    Docker is installed and ready. Would you like me to run any containers?

You: Yes, run nginx

AI: Starting nginx container...
    ✓ nginx is now running on port 80

Configuration Options

While you can provision with natural language, here are the options you can specify:

Compute classes

Size and price are one choice, from router 0.4.101. Pick a class:

Class	Shape	Price
small (default)	0.25 vCPU / 0.5 GiB	$0.02 / hour
medium	1 vCPU / 2 GiB	$0.06 / hour
large	2 vCPU / 4 GiB	$0.12 / hour
xlarge	4 vCPU / 8 GiB	$0.24 / hour

large and xlarge are new in router 0.4.103. From medium up each class doubles the previous one in size and in price — $0.06 per vCPU-hour — and the rate is the same on every plan: a larger plan includes more compute, not cheaper hours.

Billed per minute of running time, from provision until you deprovision, rounded up to whole minutes with a one-minute minimum per task. Your plan includes an amount of compute each month — $1 on Free, $5 on Pro, $50 on Business — spendable on any class at any concurrency, at the class rates. $1 is 50 hours of a small machine; a medium hour costs three times as much, a large hour six times, and eight machines running for an hour cost the same as one machine running for eight. On Pro and Business, compute continues past the included amount and is paid from credit, from $0.02 / h. See Provisioned compute.

Example:

Provision a medium node called build-runner

All four classes can be started, from router 0.4.144. large and xlarge were priced and accepted before the machines behind them existed, so a request for one could be accepted and then fail to start; that capacity is in place and an xlarge node has been provisioned and run. ⚠ An xlarge machine fills a host on its own, so asking for several of the big classes at once means the later ones wait while capacity is added rather than starting straight away.

The memory in a class is a hard limit

From router 0.4.144 a provisioned machine is held to the memory its class buys — a small node gets 0.5 GiB and no more. A process that grows past it is killed by the kernel (an out-of-memory kill inside your own container, not a noBGP refusal), so a build that needs more memory wants a bigger class, not a retry.

The vCPU figure works the other way: it is a share rather than a ceiling. It decides how much CPU your machine wins when the host is busy, and on an otherwise idle host a task can use more than its share. Size on memory.

⚠ Arbitrary CPU and memory numbers are no longer accepted. Through router 0.4.100 you could ask for any shape; it was then silently rounded up to the nearest power of two, so what you got often was not what you asked for — and a shape outside this list has no price behind it. Asking for one now comes back as an argument error naming the four classes. The default is unchanged: a request that names no class gets small, the same 0.25 vCPU / 0.5 GiB an unspecified size always produced.

The response reports the class you were actually given alongside the shape it allocated — small (0.25 vCPU / 0.5 GiB) — so it is worth reading back rather than assuming.

How long it runs

Every machine you provision stops on its own, and by default that is 24 hours later (router 0.4.117). You set it when you start the machine, and the answer comes back with the exact time it will stop, so you never have to work it out:

You: Provision a build-runner for the weekend — I need it for three days

AI: ✓ Provisioned build-runner (medium)
    It stops on its own at 2026-09-05T18:00:00Z.
    Deprovision it earlier to stop paying earlier.

What you ask for	What you get
Nothing	The plan's default: 24 hours, on every plan
A number of hours	That many hours, up to your plan's maximum — seven days on Free, no maximum on the paid plans
No deadline at all	Every plan but Free — one machine at a time, asked for deliberately

The maximum is your plan's, from router 0.4.155. Free machines can be given up to seven days at a time; Pro, Business and Enterprise have no maximum, since the same call can ask for no deadline at all. Asking for longer is refused with the number of hours the plan allows, so the retry is not a guess — and on Free you can always move the deadline again while the machine runs. Before that release every plan shared one bound of a year, which bounded nothing on Free and meant nothing anywhere else.

Free cannot turn the deadline off, because the deadline and the included compute are the only two things bounding a Free machine. Asking for it there is refused, and the refusal names the default so the retry is obvious — ask for more hours instead. Enterprise takes the same 24-hour default as Business and turns it off per machine like Pro and Business — it used to have none at all, and being unmetered is a statement about the invoice rather than about the machine.

You can move the deadline while the machine runs, in either direction, with task_deadline_set (router 0.4.125) — it is the only way to keep a machine that is still working. Provisioning the same name again does not renew it: the running task holds the name, so you get a second machine as <name>-1 and the first still stops on time, taking its disk with it.

At the deadline the machine stops the way it stops when noBGP stops it for you: its name, labels, role grants and node storage area stay, and the container and everything on its own local disk go. Provision the same name again and you have it back, on a fresh deadline.

The deadline is a reminder, not a limit. It costs nothing, it does not reduce your included compute, and starting the machine again costs nothing beyond the compute it then uses. It exists because a machine nobody remembers is the one way compute gets expensive.

Being warned before a machine stops

noBGP can email you before a machine reaches its deadline, and again when it stops. The setting is on your account page in the app, under Compute time limit, and it is off until you turn it on:

• Email me before a machine reaches its time limit — the switch. It controls the email and nothing else.
• When to warn me — 15 minutes, 30 minutes, 1 hour or 2 hours before. One hour by default.

The warning time is yours, not the machine's. Two people in the same organization who both turn it on are each warned at their own time, for the same machine.

The notice in the app does not need the setting. Above a machine whose deadline is close, the app reads Stops in 41m with Give more time beside it, and a machine that reached its limit reads Stopped at its time limit — which is how you tell it from one somebody stopped. The notice uses the same warning time as the email, whether or not the email is on.

Who gets the email: the person who provisioned the machine. If that person has left the organization, the organization Owners who turned the setting on get it instead.

• Move the deadline and the warning arms again for the new time, so extending a machine never costs you the next warning.
• A deadline already past sends no warning — the stop notice is the email for that machine.
• Two hours is the longest warning offered, because the notice in the app shows for the whole of it. A default machine only runs for 24 hours, so a longer warning would sit on the screen for most of its life.
• ⚠ The warning cannot be shorter than 15 minutes. Deadlines are checked on a sweep, so a shorter warning can fall between two checks and never be sent.

Changing the deadline of a machine that is still running

From router 0.4.125 you can move a running machine's deadline, in either direction, without losing anything on it — and it is the only way to keep a machine whose deadline is approaching:

You: build-runner stops in an hour and it's still compiling — give it four more

AI: ✓ build-runner now stops at 2026-09-04T02:11:07Z (UTC)
    The deadline moved later, from 2026-09-03T22:11:07Z.

• The hours count from now, not from when the machine started: four more hours is four hours from the moment you ask, whatever it has already run.
• Ask for nothing at all and the deadline resets to your plan's default from now, which is what renewing a machine you still want looks like.
• A smaller number is accepted and brings the stop forward. It does not stop the machine on the spot — the stop lands at the new deadline and can be a few minutes late, so deprovision it to stop paying now.
• Turning it off entirely is the same per-machine choice as at provision time: every plan but Free.
• Only a machine that is still running can be changed. A machine that has already stopped is refused, and provisioning the same name again is what brings the node back.

⚠⚠ Re-provisioning is not a renewal of the machine. Provisioning the same name again renews the node — its identity, labels, grants and storage area. While the machine is still running it does not even give you the name back: the open task holds it, so you get a suffixed name and a second, empty machine, both billing, while the first still stops at its deadline and takes its local disk with it. Through router 0.4.124 that was the only option; it never was a way to keep what was on the machine.

What the deadline does not do

• It is not retroactive. A machine provisioned before router 0.4.117 carries no deadline and still runs until you deprovision it — nothing was stamped onto a container whose owner was told otherwise.
• It cannot tell working from idle. A machine doing nothing still runs until its deadline. Automatic idle-stop is designed and not built.
• The stop can land a few minutes late. Deadlines are checked on a sweep rather than by a per-machine timer, so a machine may run slightly past the time it was given — never short of it.

Network

Specify which noBGP network the node should join:

Provision a node in my production network

If not specified, the default network is used.

Node Name

You can suggest a name:

Provision a node called "api-server-3"

Or let the AI choose a sensible default.

Who may use it

You own the machine you provision, which makes you its controller: you rename it, configure it, publish its services, decide who else may use it, and stop or remove it, whatever your organization role.

Who else may use it is decided at creation and changeable afterwards (access, router 0.4.179):

Provision a private node called "laptop-lab" in my team network

• follow (the default) — the node follows its network. While the network's access is org, every member of the organization may use it: run commands, read and write files, read its telemetry. Never as root, and never its own agent log — that needs control.
• private — only you, the organization's Owners and Admins, and the members you name on its access list.

It is written once, onto the node the container creates, so a node asked for privately is never shared for a moment. Change it later with node_access_set, and name people with node_access_grant. The whole model is What you can have on a node.

Advanced Provisioning

Provisioning with Post-Install Commands

You can request software installation during provisioning:

Provision a node with Docker and PostgreSQL installed

The AI will provision the node and then run the necessary installation commands.

Multiple Nodes

Need more than one?

Provision 3 nodes for a Kubernetes cluster

The AI will create multiple nodes in sequence or parallel.

The OS image, region, and disk are managed by noBGP — every provisioned node runs the same maintained Linux image, Ubuntu 24.04 LTS. See Compute Nodes for what is installed, which account runs your commands, and what stays when the machine stops.

What image a node runs

Every provisioned node starts from the image of the latest agent release: Ubuntu 24.04 LTS on arm64, with the noBGP agent and a set of tools installed. Compute Nodes describes the image, lists its packages, and shows how to see what is installed on a machine.

Monitoring Provisioning Status

During Provisioning

Your AI assistant will provide real-time updates:

Creating instance... ⏳
Installing agent... ⏳
Configuring network... ⏳
Node online! ✓

The node does not exist the moment provisioning returns. The call returns once the container has been created; the node itself is only registered when the agent inside it comes up and introduces itself, typically within a minute. So a listing taken immediately will not show it, and that is not a failure — the assistant waits for the node's presence events rather than asking again straight away. From router 0.4.84 the one to wait for is ready, not online: a provisioning node's connection comes up, drops and comes back — measured, five transitions in 1.5 seconds — so the first online names a session that is about to die, while ready means one has held for 5 seconds and will still be there when the next call lands. On an isolated network, which carries no event bus, it polls for the name instead.

The name you get back is the one the container will register under, and it is not always the one you asked for: it is normalized, and from router 0.4.112 it is suffixed when a live node already holds your name — or, from router 0.4.113, when the name is contested. Read it off the response rather than assuming.

After Provisioning

Check your nodes anytime:

Show me all my provisioned nodes

or

What's the status of dev-server-1?

Managing Provisioned Nodes

Running Commands

Once provisioned, you can immediately use the node:

Run "df -h" on dev-server-1

Installing Software

Install nginx on dev-server-1

Installing a database server on an older provisioned node

Packages whose install script waits for a process to disappear — measured on mysql-server, which polls for three minutes and then gives up — could hang and end up half-installed on a provisioned node, reporting Unable to shut down server. The database itself was fine; only the detection failed, because nothing in the container was reaping finished processes, so the one it was waiting for stayed listed forever.

Node images built from agent 0.4.83 onwards run a small init process that reaps them, and the same install finishes in seconds. A container provisioned before that keeps the image it started with — provision the name again to move it onto a current image, which brings the node back with its identity, labels and grants intact.

Creating Services

Publish a browser terminal for dev-server-1

Stopping a machine and keeping the node

From router 0.4.149 you can stop a provisioned machine without giving up the node it ran — task_stop, which is Stop in the web app where deprovisioning is Terminate.

Stop build-runner, but keep the node — I'll want it back tomorrow

The container stops, its billing stops, and everything on the container's own disk is destroyed. The node stays in your directory as an ordinary offline node, with the same node ID, name, labels, role grants and node storage area — exactly the state a machine reaches at its own deadline. Provision the same name again and a new machine starts on that same node.

Which of the two you want comes down to one question: do you still want the node?

	Stop (task_stop)	Terminate (deprovision_node)
Container and its billing stop	✓	✓
Everything on the container's disk	gone	gone
The node	stays, offline	leaves the directory
Node ID, labels, grants, node storage	kept	kept, and come back on re-provision
The network can then be deleted	— the node still holds it	✓ once every node has gone

• It waits for the machine to stop, up to 35 seconds, for the same reason deprovisioning does — so that provisioning the name again immediately does not collide with a machine that is still on its way down. The same node_offline field reports the outcome.
• It tells you whether the name will start it again, from router 0.4.151. Keeping the node is only worth something if provisioning its name comes back to this node, and a few things break that link — the node was revoked, a newer machine already owns it, the name is contested. Each of those looks identical from the outside, so the answer is reported as restartable_by_name: true means the name starts this node again, false means it does not and the notes say why, and an absent field means the node still reads online so the answer is not settled yet. See Will the name start it again?.
• Stopping something already stopped is success, not an error. A machine its deadline already took, or one that crashed, answers already_stopped: true, and a stop that was already recorded is not rewritten — so it is safe to issue when you are not sure.
• It stays available to an account whose provisioning was revoked, like Terminate and unlike provisioning: revoking an account must never leave machines running and billing with nothing able to stop them.
• ⚠ It does not pause anything. There is no suspend and no snapshot: the container's memory and local disk are gone, and the replacement starts its processes fresh. What survives is everything on the shared drive, including the machine's own node/ area.
• ⚠ To keep a machine that is still working, move its deadline instead. Stopping and re-provisioning costs you the container's disk; task_deadline_set costs you nothing.

Deprovisioning Nodes

When you no longer need a node — the node itself, not just the machine running it — you can deprovision it to stop incurring costs. To stop the machine and keep the node, stop it instead.

How to Deprovision

Deprovision dev-server-1

or more explicitly:

Delete the node called dev-server-1 and remove it from my network

Who may stop or remove a machine

Control of the node — its owner, or an Owner or Admin of its organization — from router 0.4.179. Stopping, deprovisioning, moving a deadline, deleting and transferring all ask the same thing. Before that release any Member of the organization could stop or remove any machine in it, including one another member had provisioned.

From router 0.4.179 there is also node_delete, which removes a node whichever way it was created: a provisioned one is deprovisioned first, an offline hand-registered one is removed, and one that is still online needs force: true.

What Happens

1. The AI confirms you want to delete the node
2. The node is gracefully shut down
3. The instance is terminated on the cloud provider
4. The node is removed from your network's directory
5. Everything on the container's own disk is gone

Data Loss

Deprovisioning permanently deletes the instance and everything written to its local disk. Make sure to back up any important data first — anything you kept on the shared drive, including the machine's own node/ area, survives.

Because the node leaves the directory, a network built entirely from provisioned nodes can be deleted through your assistant once every node has been deprovisioned. Nodes you installed the agent on yourself still have to be removed in the web dashboard first.

Deprovisioning waits for the machine to stop

From router 0.4.120 the call waits for the node to go offline before it answers — up to 35 seconds — so "deprovision it and bring it back under the same name" works as one step.

Stopping a container is asynchronous: the provider is asked, and answers at once, while the machine then takes its shutdown signal and its connection closes a moment later. Through router 0.4.119 the call returned at the first step, so re-provisioning the same name immediately arrived while the node still looked online, that was read as a live collision, and what came back was a suffixed name, a new node, and an empty storage area — a result that looks like success unless you compare the name you got against the name you asked for.

Your assistant sees the outcome in a node_offline field: true means the name is reusable now, false means the wait ended without confirming that and it should watch the directory until the node is gone before provisioning, and an absent field means no wait was needed — the task had no node, or a newer provision already owns it.

⚠ false does not mean the deprovision failed. The teardown happened and the billing stopped; what is missing is only the confirmation that the name is free. The response says so in words as well.

⚠ The call now takes noticeably longer — up to 35 seconds rather than about one — in the case where the machine is slow to stop. That is the wait doing its job.

Provisioning the same name again brings the node back

Deprovisioning retains the node's identity. Provision the same name into the same network later and you get the same node back — same node ID, same labels, same role grants, and the same node storage area. Only the container's local disk is new.

You: Provision dev-server-1 again

AI: dev-server-1 is coming back as the same node — its labels, role
    grants and node storage area are intact.
    ✓ Provisioned; registration takes about a minute

Your assistant sees this in the readopted_node_id field on the response, which is present only when the call replaces a node rather than creating one.

The storage area comes back only within 30 days (router 0.4.73). A deprovisioned node keeps its files for a month, after which they are queued for deletion and removed about a week later — so a node parked for a week or two returns exactly as it was, while one brought back after five weeks returns with its id, labels and grants and an empty storage area. The identity itself is kept indefinitely; only the files have a clock on them.

What happens to a name somebody is already using:

The node holding the name	Result
Offline, or previously deprovisioned	Replaced — the identity comes back with it
Online right now, or still has a provisioning task you never deprovisioned	Suffixed — you get the next free name in the family instead, and a new node
Contested — another node that still exists was renamed off this name and is not answering (router 0.4.113)	Suffixed — the identity behind the name you asked for is not handed over, because noBGP cannot confirm whose it is
Revoked	Refused — it could never register again

Who created the node is deliberately not one of the conditions: a name that an offline node you installed by hand is holding will be replaced too, and the container then claims that node's identity. Rename or deprovision deliberately rather than relying on a refusal to protect a name you still want.

A name already in use is suffixed, not refused

From router 0.4.112, asking for a name that a live node already holds gets you the next free name in the family — <name>-1, then -2, and so on — rather than a refusal. "Live" means the node is online, or a container was started for that name and never deprovisioned; from router 0.4.113 a contested name is suffixed the same way. Nothing about the running machine changes. If the name you asked for already ends in a number, the search starts after it: web-3 gets you web-4, never web-3-2.

⚠ The name you get back is the one to use. The response's node_name is the only place the suffix appears, so an assistant that assumes the name it typed will address the other machine on every call after this one.

You: Provision a node called build-runner

AI: build-runner is already in use, so I provisioned build-runner-1.
    ✓ build-runner-1 — registration takes about a minute

Ask for a different name, or deprovision the one that is running, if a second machine is not what you wanted. A revoked node is still a refusal: a revocation is about the identity rather than the name, so moving you onto a free name would quietly hand you a working node instead of telling you the credential was withdrawn.

Each refusal says which case applied and suggests a free name, so an assistant can retry without guessing.

Deprovisioning something that has already stopped — because it was torn down out of band, or aged out on the provider's side — succeeds and says so, rather than reporting a failure. Already-stopped is the state you were asking for, reached earlier, and nothing is billing either way. So it is safe to ask again when you are not sure whether the first attempt landed.

Renaming a provisioned node keeps its deprovision handle

A provisioned node carries a task id — the handle that stops its container and its billing, and the thing that tells a provisioned node from one you installed the agent on yourself. From router 0.4.111 that handle follows the node's identity, so renaming the node keeps it.

Through router 0.4.110 it followed the name the node was provisioned under, which the rename left behind. Three things went wrong from that one point, and all of them are fixed:

• The node reported no task id at all, so your assistant saw it as a hand-registered machine and had no way to deprovision it — while the container kept running and kept billing.
• Provisioning that name again was accepted even though a container was still running behind it, which puts two containers under one identity, each evicting the other's connection.
• Deprovisioning an older, superseded task could remove the node the new container was running as.

⚠ Let a replacement come up before renaming it. A task has no node identity to be matched on until its container connects, so a node brought back under the same name and then renamed before that new container connects reports its previous task id for the minute or so in between. Wait for the node to be ready, and re-read it after any rename before acting on what it reports.

⚠ A rename changes which name brings this machine back. Re-adoption is by name, so once a provisioned node is renamed, provisioning its old name starts a new machine and provisioning its new name is what re-adopts this one. From router 0.4.120 your assistant can perform the rename itself with node_rename; before that it was a web-app action.

Safety Confirmations

The AI will ask for confirmation before deprovisioning:

You: Deprovision dev-server-1

AI: Are you sure you want to deprovision dev-server-1? This will:
    - Terminate the AWS instance
    - Remove it from your network
    - Delete all data on the node

    This action cannot be undone. Should I proceed?

You: Yes, proceed

AI: Deprovisioning dev-server-1...
    ✓ Instance terminated
    ✓ Node removed from network

When noBGP stops a machine

A provisioned machine is stopped rather than deleted. Five things reach that state, and they all land in the same one:

• You stopped it yourself (router 0.4.149)
• The machine reached its deadline — the bound you asked for when you provisioned it, or the plan's 24-hour default (router 0.4.117)
• The organization used up its included compute — on Free, where there is no overage and no bill
• On a paid plan, the included compute is used up and the credit balance behind it is empty (router 0.4.128)
• Its payment lapsed

The first two are things you asked for and the other three are lines the platform enforces, but the machine ends up in the same place either way.

⚠ The money that stops a paid organization's machine is the balance, not the spend cap. Compute past the included compute allowance is drawn from the credit balance, and from router 0.4.128 an empty balance stops the machines already up as well as refusing a new provision — the same state, and the same sweep, as a deadline, within about ten minutes. Buying credit is what clears it; the fleet is also slowed while the balance is empty. The spend cap stops nothing directly, because it bounds automatic top-ups. ⚠ From router 0.4.135 raising it can start the machines again indirectly, and only with an automatic refill rule armed: the raise attempts the refill it has just permitted, and it is the credit that arrives that lifts the stop. Through router 0.4.126 the cap did stop machines, and since it starts at $0, a paid organization that had never raised it was stopped at the included compute exactly like Free; router 0.4.127 moved the creation gate onto the balance and left running machines alone for one release, which left an empty balance with no line on compute at all.

What survives

Kept	Gone
The node's identity — same node_id, same name	The container, and everything on its local disk
Its labels and role grants	Whatever was in memory: processes start fresh next time
Its node storage area, which keeps counting against the plan's storage limit	The compute charge — a stopped machine costs nothing

What you are left with is an ordinary offline node — online: false in network_directory, with an offline_at saying when it went. There is no separate state to check for.

There was a "suspended" state, and router 0.4.112 removed it

Through router 0.4.111 a machine stopped this way was described as suspended: the directory carried a suspended_at timestamp, and a node left that way was deprovisioned for real after 48 hours on Free, 30 days on Pro or 90 days on Business.

Both are gone. A node has three states — online, offline, deprovisioned — and a stopped machine is simply offline, so there is no marker to look for and no timer counting down. An offline node lives for as long as you keep it; what bounds its stored files is the plan's storage limit, which you are already paying against. Nothing was ever reported in the old field, because the enforcement it depended on has not been switched on, so no organization loses an answer it was getting.

Starting it again

Provision the same name again — that is the whole of it, and there is no separate resume command:

You: build-runner stopped. Bring it back.

AI: build-runner is offline — noBGP stopped its machine when the compute
    allowance ran out. Your period rolls over on the 1st, or you can
    upgrade the plan.
    ✓ Provisioned again — same node, same labels, same storage area

Nothing else has to be reattached.

⚠ There is still no idle timer. A provisioned node you have stopped using keeps running, and keeps drawing your compute budget, until its deadline, until you deprovision it, or until the budget runs out — the deadline bounds how long a machine runs, not how long it sits idle. Deprovision what you are not using.

Cost Management

Understanding Costs

Provisioned nodes run in noBGP's managed cloud account. Their traffic counts on the bandwidth meter, and the class you pick is what the compute itself costs per hour — billed by the minute against the compute your plan includes, then metered above it. See Plans & Billing.

The breakdown per class — billed hours, cost, and what is left of the month's included compute — is available to any member of the organization through the compute_usage operation on the REST surface.

tip

Deprovision nodes when not in use to minimize costs. You can always provision new ones when needed.

Checking Costs

Ask your AI assistant:

How many nodes do I have running?

This helps you keep track of your infrastructure and associated costs.

Best Practices

1. Deprovision dev/test nodes when not actively using them
2. Use smaller instances for development and testing
3. Monitor your fleet regularly with "show me all my nodes"
4. Name nodes descriptively to track purposes

Common Provisioning Workflows

Development Workflow

You: I need a dev environment for Python work

AI: I'll provision a node with Python 3.11 for you...
    ✓ Node "python-dev-1" is ready

You: Install poetry and create a virtual environment

AI: [Installs poetry and sets up venv]
    ✓ Ready for development

[Work on your project...]

You: I'm done for today, deprovision the node

AI: Deprovisioning python-dev-1...
    ✓ Node removed

Cost: The node's compute bills by the minute, only while it exists.

Testing Workflow

You: Provision 2 nodes for load testing my web app

AI: [Provisions 2 nodes]
    ✓ load-test-1 ready
    ✓ load-test-2 ready

You: Run apache bench on both nodes targeting my app

AI: [Runs load tests simultaneously]
    [Reports results]

You: Deprovision both load test nodes

AI: [Deprovisions both]
    ✓ Both nodes removed

Staging Environment

You: Provision a staging server matching my production specs

AI: [Provisions node with the same class as production]
    ✓ staging-server-1 ready

You: Deploy my app from the GitHub main branch

AI: [Clones repo, installs dependencies, starts app]
    ✓ App running on port 3000

You: Publish it as a web service with auth required

AI: [Creates public HTTPS URL]
    🔗 https://abc123.nobgp.link (auth required)

Troubleshooting

Provisioning Fails

Error: "you are not permitted to provision nodes"

Solution: This is no longer an access tier you have to be granted — from router 0.4.110 every account may provision, so a forbidden here means provisioning was revoked for the account specifically, which only happens deliberately. Contact us. Note that stopping what is already running is not gated the same way: deprovision_node keeps working, so nothing can be left running and billing with no way to stop it.

Error: "Quota exceeded"

Solution: Deprovision unused nodes, or upgrade your plan for a larger allowance.

Error: "this month's included compute is used up"

Solution: The organization has spent its month's compute allowance. Wait for the period to roll over, or upgrade the plan. Nodes whose machines were stopped for this reason are not lost; provisioning the same name again brings them back.

Error: "usage credit is empty"

Solution (paid plans, router 0.4.127+): the organization has used up an included allowance and has no credit left to draw on, so it may not add billable resources. Buy credit — credit op=buy from Account → Billing — or wait for the period to roll over, when the included allowance comes back. Raising the spend cap does not clear this one directly: the cap bounds automatic top-ups, and this gate reads the balance. ⚠ It can clear it indirectly, from router 0.4.135, and only if you have an automatic refill rule armed: raising the maximum attempts the refill it has just permitted, and it is the credit that arrives — not the new number — that clears the refusal. With no rule armed, raising the cap buys nothing and changes nothing here.

Node Doesn't Come Online

If a provisioned node doesn't show as "online" after 2-3 minutes:

1. Ask the AI: "What's the status of [node-name]?"
2. Check if the provisioning task completed successfully
3. Deprovision the task, then provision the same name again — the replacement container comes back as the same node. Do deprovision first: provisioning the name while the first task is still open gets you a suffixed name and a second machine, precisely because a container may still be running behind a node that reads as offline. From router 0.4.120 the deprovision waits for the machine to stop, so the two steps can be run back to back
4. Contact support if the issue persists

Can't Connect to Provisioned Node

If the node is online but commands fail:

1. Verify the node is in the correct network
2. Check the node status: "Show me details for [node-name]"
3. Try restarting the agent: "Restart the noBGP agent on [node-name]"

Unexpected Costs

If your usage is higher than expected:

1. List all running nodes: "Show me all my nodes"
2. Deprovision any you don't recognize
3. Review your provisioning history

Provisioned nodes run in noBGP's managed cloud account. Their traffic counts on the bandwidth meter, and the class you pick is what the compute itself costs per hour — billed by the minute against the compute your plan includes, then metered above it. See Plans & Billing.

The breakdown per class — billed hours, cost, and what is left of the month's included compute — is available to any member of the organization through the compute_usage operation on the REST surface.

Limits and Quotas

No plan caps how many nodes you may have, from router 0.4.106 — Free's 25-node cap is gone and every plan is unlimited. Nodes stopped being a meter in router 0.4.101 and have now stopped being a limit as well: a device that moves no data costs nothing to keep connected, so what bounds an organization is the traffic its fleet moves. The paid plans carry a stated fair-use ceiling (about 1,000 live nodes on Pro, 5,000 on Business) that nothing enforces. See Plan limits.

Compute is the gate that remains, from router 0.4.103. Every provision is checked against the month's included compute and against the money behind it, on the organization that will be billed for it. A refusal names how much of the allowance is used against how much is included, and says that running machines are stopped rather than destroyed:

this month's included compute is used up (50 h of 50 h) — running machines are
stopped and keep their names, permissions and files; upgrade for more, or start
them again next month

⚠ The refusal quotes the allowance in hours — hours of a small machine, converted from the dollar amount your plan includes. Plans & Billing and the usage page in the app state the dollars.

On a paid plan the money check is the credit balance, from router 0.4.127 — a provision is refused only once an included allowance is used up and the balance behind it is empty (limit_type: "credit_empty"), and buying credit clears it. Through router 0.4.126 the check was the spend cap instead, which starts at $0, so a paid organization that had never raised it was refused at the same point a Free one is — and could not buy its way past, because the gate never looked at the balance. See an empty balance is what refuses creation.

Bringing a deprovisioned node back still goes through the compute gates, because the container it starts meters compute like any other. Replacing a node that is still in the directory does too, for the same reason.

To check your limits:

What are my provisioning limits?

Next Steps

Now that you understand provisioning:

• Publishing Services - Expose your provisioned nodes to the internet
• Interactive Terminals - Access your nodes through a web browser
• Use Cases & Examples - See real-world provisioning scenarios

FAQ

Q: How long does provisioning take? A: Typically 1-2 minutes from request to ready-to-use.

Q: Can I provision nodes in my own AWS account? A: Not currently. noBGP provisions nodes in managed cloud accounts. Self-hosted provisioning is on the roadmap.

Q: What happens to my data when I deprovision? A: Everything on the container's own disk is permanently deleted. Use the file sharing feature or external storage for anything that has to outlive the container — a node's own storage area survives deprovisioning for 30 days and comes back with the node if you provision the same name again inside that window.

Q: Can I get a node back after deprovisioning it? A: The machine, no — the container and its local disk are gone. The node's identity is another matter: provision the same name into the same network and you get the same node ID, labels, role grants and — within 30 days — node storage back. See Provisioning the same name again.

Q: Can I SSH into provisioned nodes? A: No — provisioned nodes have no public IP or SSH access. Use command sessions or a browser terminal through noBGP instead.

Q: Do provisioned nodes persist after I log out? A: Yes — a provisioned node keeps running after you disconnect, until you deprovision it or it reaches its deadline, which is 24 hours by default. Deprovision what you are not using rather than letting the deadline do it: you stop paying at the moment you deprovision.

Q: How do I stop a machine running for longer than I meant it to? A: Every machine provisioned from router 0.4.117 has a deadline and stops on its own — 24 hours unless you asked for something else. Ask for the hours you need when you provision, up to your plan's maximum — seven days on Free, no maximum on the paid plans; on every plan but Free you can ask for no deadline at all, for one machine at a time. The response always says the exact time the machine will stop.

Q: My machine is about to hit its deadline and it is still working. How do I keep it? A: Ask for more time — from router 0.4.125 a running machine's deadline can be moved in either direction and nothing on the machine is lost. See Changing the deadline of a machine that is still running. Do not re-provision the same name to renew it: the running machine holds the name, so you get a suffixed name and a second machine billing beside the first, which still stops on time and takes its disk with it.

Q: How do I find out when a machine is going to stop? A: Ask for the machine's status — from router 0.4.125 the directory reports each provisioned node's deadline as task_deadline_at, so you can read it for a machine you did not provision yourself in this session. Nothing there means the node is not cloud-provisioned, its machine has already stopped, or it genuinely has no deadline.

Q: Can I change the size of a provisioned node? A: Not while it is running — but you do not have to give up its identity. Deprovision it, then provision the same name again with a different class: the replacement container comes back as the same node, with the same labels, role grants and storage area, on the new shape. Only what was on the container's local disk is lost.

Q: One of my provisioned nodes went offline on its own. What happened? A: If nothing on the machine explains it, its compute was stopped — most often because it reached the deadline it was given when it was provisioned (24 hours unless you asked for something else), and otherwise because a Free organization reached its included compute, or a payment failed. See When noBGP stops a machine. Nothing was deleted, and provisioning the same name again brings it back. There is no separate marker to look for: a stopped machine leaves an ordinary offline node.