ultanio/cobot

Fork 4

Feature: BitLaunch Plugin — Dedicated Server Management (Pay with Bitcoin) #95

New issue

Open

opened 2026-02-25 17:36:58 +00:00 by Zeus · 1 comment

Zeus commented

2026-02-25 17:36:58 +00:00

Collaborator

Summary

Plugin for provisioning and managing dedicated servers via the BitLaunch API. Cobots can spin up infrastructure on demand and pay with Bitcoin/Lightning — no credit card, no KYC, full sovereignty.

Python SDK: https://github.com/BitLaunchIO/pybitlaunch
API docs: https://developers.bitlaunch.io/

Why This Matters

The missing piece in cobot infrastructure autonomy. Combined with #93 (Namecheap domains) and #94 (OpenRouter models), a cobot can:

Provision a server (BitLaunch) → pay with Lightning
Register a domain (Namecheap) → point DNS to the server
Run any model (OpenRouter) → on its own terms

Fully autonomous infrastructure. No human in the loop for routine ops.

Scenarios

1. Self-Provisioning Cobot

A cobot needs more compute for a heavy task. It provisions a server on BitLaunch, deploys its workload, runs the job, tears down the server. Total cost: a few thousand sats. No human involved.

2. Cobot-as-a-Service Deployment

User asks for a new cobot instance. The orchestrator cobot spins up a BitLaunch server, installs the cobot framework, configures it, registers a domain (#93), and hands over the keys. Fully automated onboarding.

3. Elastic Scaling

Cobot monitors its own load. When requests spike, it provisions additional servers. When load drops, it tears them down. Pays per hour via Lightning. Cloud-like elasticity without cloud lock-in.

4. Geographic Distribution

Cobot deploys instances across regions for latency optimization. BitLaunch supports multiple providers (DigitalOcean, Vultr, etc.) — cobot picks the best region/provider combo.

5. Disaster Recovery

Primary server goes down. Cobot detects the failure, provisions a replacement on BitLaunch, restores from backup, updates DNS (#93), and is back online. Automated failover.

6. Pay-Per-Use Agent Economy

Agent A needs a temporary GPU server for ML inference. Agent B (infrastructure agent) provisions it via BitLaunch, charges Agent A via Lightning for the duration. Server economy between agents.

Core Operations

Operation	SDK Method	Safety Level
List servers	`Servers.List()`	Safe
Show server	`Servers.Show(id)`	Safe
Create server	`Servers.Create()`	🔴 Costs money — requires confirmation
Destroy server	`Servers.Destroy(id)`	🔴 Destructive — requires confirmation
Rebuild server	`Servers.Rebuild(id)`	🔴 Destructive
Resize server	`Servers.Resize(id)`	⚠️ May change cost
List SSH keys	`SSHKeys.List()`	Safe
Create SSH key	`SSHKeys.Create()`	Safe
Account usage	`Account.Usage()`	Safe
Create transaction	`Transactions.Create()`	🔴 Sends money

BitLaunch Features

Bitcoin/Lightning payments — top up account with sats
Multiple providers — DigitalOcean, Vultr, etc. through one API
Hourly billing — pay only for what you use
SSH key management — deploy keys programmatically
Transaction history — full audit trail

Technical Notes

Python SDK: pip install pybitlaunch
Auth: Bearer token via pybitlaunch.Client(token)
REST API also available directly
Could wrap as MCP server for mcporter

Safety

Server creation requires explicit confirmation with cost estimate
Server destruction requires confirmation with server name/ID
Budget caps: max monthly spend, max concurrent servers
Auto-destroy idle servers after configurable timeout
Full audit log of all provisioning actions

The Sovereignty Stack

With this + #93 + #94, cobots have a complete autonomous infrastructure:

┌─────────────────────────────────────┐
│  OpenRouter (#94) — Model Access    │
├─────────────────────────────────────┤
│  BitLaunch (#95) — Compute          │  ← all paid with
├─────────────────────────────────────┤     Bitcoin/Lightning
│  Namecheap (#93) — Domains/DNS      │
└─────────────────────────────────────┘

Open Questions

Shell, Python, or MCP server?
Auto-provisioning policies (when can a cobot self-provision without human approval)?
Provider preferences (DigitalOcean vs Vultr vs others)?
Integration with cobot deployment scripts?
Lightning auto-topup when balance runs low?

## Summary Plugin for provisioning and managing dedicated servers via the BitLaunch API. Cobots can spin up infrastructure on demand and pay with Bitcoin/Lightning — no credit card, no KYC, full sovereignty. Python SDK: https://github.com/BitLaunchIO/pybitlaunch API docs: https://developers.bitlaunch.io/ ## Why This Matters The missing piece in cobot infrastructure autonomy. Combined with #93 (Namecheap domains) and #94 (OpenRouter models), a cobot can: 1. **Provision a server** (BitLaunch) → pay with Lightning 2. **Register a domain** (Namecheap) → point DNS to the server 3. **Run any model** (OpenRouter) → on its own terms Fully autonomous infrastructure. No human in the loop for routine ops. ## Scenarios ### 1. Self-Provisioning Cobot A cobot needs more compute for a heavy task. It provisions a server on BitLaunch, deploys its workload, runs the job, tears down the server. Total cost: a few thousand sats. No human involved. ### 2. Cobot-as-a-Service Deployment User asks for a new cobot instance. The orchestrator cobot spins up a BitLaunch server, installs the cobot framework, configures it, registers a domain (#93), and hands over the keys. Fully automated onboarding. ### 3. Elastic Scaling Cobot monitors its own load. When requests spike, it provisions additional servers. When load drops, it tears them down. Pays per hour via Lightning. Cloud-like elasticity without cloud lock-in. ### 4. Geographic Distribution Cobot deploys instances across regions for latency optimization. BitLaunch supports multiple providers (DigitalOcean, Vultr, etc.) — cobot picks the best region/provider combo. ### 5. Disaster Recovery Primary server goes down. Cobot detects the failure, provisions a replacement on BitLaunch, restores from backup, updates DNS (#93), and is back online. Automated failover. ### 6. Pay-Per-Use Agent Economy Agent A needs a temporary GPU server for ML inference. Agent B (infrastructure agent) provisions it via BitLaunch, charges Agent A via Lightning for the duration. Server economy between agents. ## Core Operations | Operation | SDK Method | Safety Level | |-----------|-----------|-------------| | List servers | `Servers.List()` | Safe | | Show server | `Servers.Show(id)` | Safe | | Create server | `Servers.Create()` | 🔴 Costs money — requires confirmation | | Destroy server | `Servers.Destroy(id)` | 🔴 Destructive — requires confirmation | | Rebuild server | `Servers.Rebuild(id)` | 🔴 Destructive | | Resize server | `Servers.Resize(id)` | ⚠️ May change cost | | List SSH keys | `SSHKeys.List()` | Safe | | Create SSH key | `SSHKeys.Create()` | Safe | | Account usage | `Account.Usage()` | Safe | | Create transaction | `Transactions.Create()` | 🔴 Sends money | ## BitLaunch Features - **Bitcoin/Lightning payments** — top up account with sats - **Multiple providers** — DigitalOcean, Vultr, etc. through one API - **Hourly billing** — pay only for what you use - **SSH key management** — deploy keys programmatically - **Transaction history** — full audit trail ## Technical Notes - Python SDK: `pip install pybitlaunch` - Auth: Bearer token via `pybitlaunch.Client(token)` - REST API also available directly - Could wrap as MCP server for mcporter ## Safety - Server creation requires explicit confirmation with cost estimate - Server destruction requires confirmation with server name/ID - Budget caps: max monthly spend, max concurrent servers - Auto-destroy idle servers after configurable timeout - Full audit log of all provisioning actions ## The Sovereignty Stack With this + #93 + #94, cobots have a complete autonomous infrastructure: ``` ┌─────────────────────────────────────┐ │ OpenRouter (#94) — Model Access │ ├─────────────────────────────────────┤ │ BitLaunch (#95) — Compute │ ← all paid with ├─────────────────────────────────────┤ Bitcoin/Lightning │ Namecheap (#93) — Domains/DNS │ └─────────────────────────────────────┘ ``` ## Open Questions - [ ] Shell, Python, or MCP server? - [ ] Auto-provisioning policies (when can a cobot self-provision without human approval)? - [ ] Provider preferences (DigitalOcean vs Vultr vs others)? - [ ] Integration with cobot deployment scripts? - [ ] Lightning auto-topup when balance runs low?

doxios added the

Kind/Feature

label

2026-02-26 12:31:39 +00:00

doxios commented

2026-02-26 12:31:39 +00:00

Collaborator

Triage Assessment

Classification: VALID-ENHANCEMENT

Analysis:
Well-structured feature proposal for autonomous server provisioning via BitLaunch. Part of the "sovereignty stack" trio (#93, #94, #95). The scenarios are compelling — self-provisioning, elastic scaling, disaster recovery.

Key observations:

Strong safety model with confirmation gates for destructive/costly operations
Budget caps and auto-destroy for idle servers are essential guardrails
Open question about shell vs Python vs MCP is important — recommend aligning with whatever #93 and #94 decide since they form a stack
Dependencies: would benefit from #91 (Secret Injection) for API key management

Suggested next steps:

Decide on implementation approach (shell/Python/MCP) across all three sovereignty stack issues together
Define auto-provisioning policy boundaries before implementation
This is a large scope — consider breaking into an Epic with stories for each operation group

Label added: Kind/Feature
Priority: Flagged for human decision

Triaged by Doxios 🦊

## Triage Assessment **Classification:** VALID-ENHANCEMENT **Analysis:** Well-structured feature proposal for autonomous server provisioning via BitLaunch. Part of the "sovereignty stack" trio (#93, #94, #95). The scenarios are compelling — self-provisioning, elastic scaling, disaster recovery. **Key observations:** - Strong safety model with confirmation gates for destructive/costly operations - Budget caps and auto-destroy for idle servers are essential guardrails - Open question about shell vs Python vs MCP is important — recommend aligning with whatever #93 and #94 decide since they form a stack - Dependencies: would benefit from #91 (Secret Injection) for API key management **Suggested next steps:** 1. Decide on implementation approach (shell/Python/MCP) across all three sovereignty stack issues together 2. Define auto-provisioning policy boundaries before implementation 3. This is a large scope — consider breaking into an Epic with stories for each operation group **Label added:** Kind/Feature **Priority:** Flagged for human decision --- *Triaged by Doxios 🦊*

doxios referenced this issue

2026-02-26 12:32:01 +00:00

Feature: Namecheap Domain API Plugin #93

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

ultanio/cobot#95

No description provided.

Rows
Columns