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.
On-demand provisioning is currently available to selected accounts. If the provisioning tools return a permission error, contact us. In the meantime, you can still connect existing infrastructure using the agent installation guide.
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
- You describe what you need in natural language
- Your AI assistant uses the
provision_nodeMCP tool - noBGP creates the instance on a cloud provider (AWS, etc.)
- The noBGP agent is automatically installed and configured
- The node joins your specified network
- 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) - Variable CPU and memory configurations via managed containers (Amazon ECS)
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:
- Choose sensible defaults (CPU and memory)
- Create the instance
- Configure it automatically
- Report when it's ready
Specifying Requirements
You can be more specific about what you need:
Provision a node with 2 vCPU and 4 GB of memory in my production network
Or:
Create a node with 4GB of RAM for my build jobs
The AI understands natural language and will translate your requirements into CPU units and MiB of memory.
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
- Resources: 2048 CPU units (2 vCPU), 4096 MiB RAM
- 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:
Resources
You can specify:
- CPU: In CPU units where 1024 = 1 vCPU (range: 256-4096, default: 256)
- Memory: RAM in MiB (range: 512-16384, default: 512)
Values are rounded up to the nearest power of two within these ranges. The response reports the shape you were actually given, not the one you asked for — that is what the node costs, so it is worth reading back.
Example:
Provision a node with 4GB RAM and 2 vCPUs
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.
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.
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 registered and then online presence events rather than asking again straight away. On an isolated network, which carries no event bus, it polls for the name instead.
The name you get back is the normalized one the container will register under; it can differ in case from the name you asked for.
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
Creating Services
Publish a browser terminal for dev-server-1
Deprovisioning Nodes
When you no longer need a node, you can deprovision it to stop incurring costs.
How to Deprovision
Deprovision dev-server-1
or more explicitly:
Delete the node called dev-server-1 and remove it from my network
What Happens
- The AI confirms you want to delete the node
- The node is gracefully shut down
- The instance is terminated on the cloud provider
- The node is removed from your network's directory
- Everything on the container's own disk is gone
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.
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.
The name is refused only where registration itself would refuse it:
| The node holding the name | Result |
|---|---|
| Offline, or previously deprovisioned | Replaced — the identity comes back with it |
| Online right now | Refused — deprovision it first, or use another name |
| Revoked | Refused — it could never register again |
| Still has a provisioning task you never deprovisioned | Refused — a container was started for this name and never stopped |
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.
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.
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
Cost Management
Understanding Costs
Provisioned nodes run in noBGP's managed cloud account and count against your plan's node allowance and usage — see Plans & Billing.
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
- Deprovision dev/test nodes when not actively using them
- Use smaller instances for development and testing
- Monitor your fleet regularly with "show me all my nodes"
- 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 counts against your plan's node allowance 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 CPU/memory shape 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.com (auth required)
Troubleshooting
Provisioning Fails
Error: "You don't have provisioning access"
Solution: Contact support to request access to provisioning features.
Error: "Quota exceeded"
Solution: Deprovision unused nodes, or upgrade your plan for a larger allowance.
Node Doesn't Come Online
If a provisioned node doesn't show as "online" after 2-3 minutes:
- Ask the AI: "What's the status of [node-name]?"
- Check if the provisioning task completed successfully
- Deprovision the task, then provision the same name again — the replacement container comes back as the same node. Provisioning the name while the first task is still open is refused, precisely because a container may still be running behind a node that reads as offline
- Contact support if the issue persists
Can't Connect to Provisioned Node
If the node is online but commands fail:
- Verify the node is in the correct network
- Check the node status: "Show me details for [node-name]"
- Try restarting the agent: "Restart the noBGP agent on [node-name]"
Unexpected Costs
If your usage is higher than expected:
- List all running nodes: "Show me all my nodes"
- Deprovision any you don't recognize
- Review your provisioning history
Provisioned nodes run in noBGP's managed cloud account and count against your plan's node allowance and usage — see Plans & Billing.
Limits and Quotas
Node allowances depend on your plan: the Free plan has a hard node cap; paid plans include an allowance with metered overage. When a cap is hit, provisioning returns a limit error with an upgrade link. See Plans & Billing.
Bringing a deprovisioned node back counts as creating one, because it rejoins your fleet. Replacing a node that is still in the directory does not — it is already counted, so an organization sitting at its cap can still re-provision in place.
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! Provisioned nodes continue running until you deprovision them. This is why it's important to clean up unused nodes.
Q: Can I change the size of a provisioned node? A: Not directly. You'll need to provision a new node with the desired size and migrate your workload.