Edge Deployments
The Deployments tab tracks the history of Vurb.ts framework deployments to your server. Each deployment is an immutable snapshot — a V8-compatible JavaScript bundle deployed to the edge runtime, identified by its SHA-256 hash, size, and timestamp.
Most MCP platforms require you to host your own server infrastructure or rely on generic container services. Vinkius Cloud provides a built-in edge deployment pipeline: write your MCP tools with the Vurb.ts framework, run vurb deploy, and the bundle is deployed to a V8 isolate runtime at the edge — zero infrastructure to manage.
Vurb.ts banner
At the top of the Deployments tab, an educational banner introduces the Vurb.ts open-source framework:
The banner is dismissible and includes direct links to the Vurb.ts documentation and the GitHub repository.
Deployment history
Deployments are listed in reverse chronological order. The active deployment is marked with a green indicator:
Table columns
| Column | Description |
|---|---|
| Active | Green dot — the currently live deployment. Only one deployment is active at a time |
| Deployed | Timestamp in MMM DD, HH:mm format |
| Hash | First 12 characters of the SHA-256 bundle hash |
| Size | Raw bundle size before compression (displayed in KB) |
| Ago | Relative timestamp — just now, 3h ago, 2d ago |
Pagination
Deployment history is paginated at 15 records per page. Navigation controls at the bottom show page position and forward/back arrows.
Getting started
When no deployments exist, the tab displays an inline getting-started guide with pre-filled commands specific to your server:
The server-id is pre-filled with your actual server ID, so you can copy the command directly from the UI.
Terminal output
After running vurb deploy, the CLI compiles your project, uploads the bundle, and displays the deploy result:
The API response includes:
| Field | Value |
|---|---|
| status | deployed for new bundles, restored when the hash matches a previous deployment |
| server_name | Name of the target server |
| url | Full MCP endpoint URL ready for AI clients |
| deployed_at | ISO 8601 timestamp |
| cache_invalidated | true when all connected clients were notified to refresh |
Restored deployments
If you deploy a bundle identical to a previous one, the system restores the existing snapshot instead of creating a duplicate. The terminal shows Restored previous deployment and the status is restored.
After deploying
When vurb deploy completes, the deployment appears in the history table and the new bundle immediately becomes the active version. If you deployed through the server creation wizard, a success screen guides you through connecting your first AI client:
What each client tab provides
| Tab | Content |
|---|---|
| Claude | OS selector (Windows, macOS, Linux) with the config file path for each platform, and instructions to merge the JSON |
| Cursor | One-click deep link (cursor://...) to install the server directly, plus manual SSE URL fallback |
| VS Code | SSE endpoint URL with step-by-step instructions (Ctrl+Shift+P → MCP: Add Server → select HTTP (Server-Sent Events)) |
| Antigravity | SSE endpoint URL with prompt instructions |
| Others | SSE endpoint URL with a list of additional supported clients: ChatGPT, Windsurf, Cline, Continue, Zed |
Deploy pipeline
When vurb deploy executes, the following pipeline runs:
| Step | Detail |
|---|---|
| Bundle | Vurb.ts compiles your project into a single V8-compatible JavaScript bundle |
| Compress | The bundle is gzipped before upload (max 750KB compressed, 512KB raw) |
| Hash | A SHA-256 hash of the raw JavaScript is computed for integrity verification |
| Upload | The compressed bundle, hash, and raw size are sent to the deploy API |
| Verify | The server decompresses the bundle and verifies the hash matches the raw content |
| Deduplicate | If the hash matches a previous deployment, it is restored instead of creating a new entry |
| Activate | The new deployment becomes the active version |
| Invalidate | All connection tokens are invalidated via mcp:invalidate — the runtime disposes old V8 isolates and boots the new bundle on next client connection |
Deduplication
If you deploy a bundle with the same hash as a previous deployment, the system restores the existing snapshot instead of creating a duplicate. The response status will be restored instead of deployed.
Authentication
Deployments are authenticated via connection tokens — the same tokens used for MCP connections. The deploy API uses the mcp.auth middleware:
- The token in the
Authorization: Bearer <token>header must belong to the target server - Revoking a token blocks all future deploys from that token
- No separate deploy key is required
Post-deploy invalidation
After a successful deployment, all connection tokens for the server are invalidated via Redis mcp:invalidate. This triggers the runtime to:
- Evict the cached server configuration
- Dispose the old V8 isolate
- Boot the new bundle on the next client connection
Connected AI clients experience a seamless transition — the SSE connection re-establishes automatically with the updated tool definitions from the new bundle.
Next steps
Frequently Asked Questions
How do I deploy an MCP server with Vurb.ts?
Three steps: (1) Run vurb remote --server-id <your-server-id> to link your project, (2) Add your connection token to .env as VURB_DEPLOY_TOKEN, (3) Run vurb deploy. The CLI compiles, uploads, and activates your bundle on the V8 edge runtime. The server-id is pre-filled in the dashboard for one-click copy.
What happens when I deploy a duplicate bundle?
If the SHA-256 hash matches a previous deployment, the system restores the existing snapshot instead of creating a duplicate. The terminal shows "Restored previous deployment" and the status is restored. This prevents unnecessary deployment entries while preserving the deploy history.
How large can a deployment bundle be?
Maximum 512KB raw JavaScript (750KB compressed). Vurb.ts compiles your project into a single V8-compatible bundle that is gzipped before upload. The SHA-256 hash is computed from the raw content for integrity verification.
Do connected AI clients need to reconnect after a deployment?
No. After a successful deployment, all connection tokens are invalidated via mcp:invalidate. The runtime disposes old V8 isolates and boots the new bundle on the next client connection. Connected AI clients experience a seamless transition — the SSE connection re-establishes automatically.
What authentication is required for deployments?
Deployments use the same connection tokens as MCP connections. Include the token in the Authorization: Bearer header. No separate deploy key is required. Revoking a token blocks all future deploys from that token.
Can I see the deployment history?
Yes. The Deployments tab shows all deployments in reverse chronological order with the active deployment marked by a green dot. Each entry shows the timestamp, first 12 characters of the SHA-256 hash, raw bundle size, and relative time since deployment. History is paginated at 15 records per page.