docs(blog): Phase 33 direct-connect migration — Cloudflare Tunnel to public IP (#1612)
* docs(social): EC2 Instance Connect SSH launch copy + terminal demo visual PR #1533 (feat/terminal: remote path via aws ec2-instance-connect + pty) Issue #1547 (social: launch thread for EC2 Instance Connect SSH) Content: - docs/marketing/social/2026-04-22-ec2-instance-connect-ssh/social-copy.md 5-post X thread + LinkedIn single post, dark theme brand voice - docs/assets/blog/2026-04-22-ec2-instance-connect-ssh/ec2-terminal-demo.png (1200x800) Canvas Terminal tab mockup showing EC2 bash prompt via EIC Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * docs(blog): Phase 33 direct-connect migration — Cloudflare Tunnel to public IP Migrate from Cloudflare Tunnel (outbound WebSocket) to direct-connect agent workspaces with per-workspace public IPs. Covers operator actions, developer notes, security model, and Phase 33 rollout timeline. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> --------- Co-authored-by: Molecule AI Social Media Brand <social-media-brand@agents.moleculesai.app> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: Molecule AI DevRel Engineer <devrel-engineer@agents.moleculesai.app>
This commit is contained in:
molecule-ai[bot]
GitHub
parent
7a89704b6e
commit
7c66c692d8
Binary file not shown.
|
After Width: | Height: | Size: 3.7 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 137 KiB |
103
docs/blog/2026-04-22-cloudflare-tunnel-migration/index.md
Normal file
103
docs/blog/2026-04-22-cloudflare-tunnel-migration/index.md
Normal file
@ -0,0 +1,103 @@
|
||||
---
|
||||
title: "Phase 33: From Cloudflare Tunnel to Direct Connect — How Molecule AI Agent Workspaces Get Their Own IP"
|
||||
date: 2026-04-22
|
||||
slug: cloudflare-tunnel-migration
|
||||
description: "Phase 33 replaces Cloudflare Tunnel with direct-connect agent workspaces that get their own public IPs. Here's what changed, why, and what it means for your deployment."
|
||||
tags: [platform, infrastructure, cloud, deployment]
|
||||
---
|
||||
|
||||
# Phase 33: From Cloudflare Tunnel to Direct Connect — How Molecule AI Agent Workspaces Get Their Own IP
|
||||
|
||||
In Phase 33, Molecule AI changes how cloud-hosted agent workspaces connect to the platform. Previously, every workspace connected outbound through a Cloudflare Tunnel — a lightweight daemon that maintained a persistent connection to Cloudflare's edge, routing traffic through their network. Starting today, workspaces provisioned in your cloud account get their own public IP addresses and connect directly, with no tunnel in the path.
|
||||
|
||||
This post covers what changed architecturally, why we made the change, and what operators and developers need to know.
|
||||
|
||||
## What was there before: the Cloudflare Tunnel model
|
||||
|
||||
Cloudflare Tunnel (formerly `cloudflared`) worked like this:
|
||||
|
||||
1. A lightweight daemon ran inside each agent workspace container
|
||||
2. It maintained an outbound-only WebSocket connection to a Cloudflare edge node
|
||||
3. External traffic (your browser, API calls, CLI commands) hit a Cloudflare-assigned hostname (`*.trydirect.io` or a custom domain via Cloudflare)
|
||||
4. Cloudflare routed that traffic through the tunnel WebSocket to the workspace
|
||||
|
||||
This was elegant for one specific constraint: **no inbound firewall rules required**. The workspace container opened only an outbound connection. Everything else was handled at Cloudflare's edge. For development environments and scenarios where you can't modify network security groups, this was a valid tradeoff.
|
||||
|
||||
The tradeoff became less acceptable at scale:
|
||||
|
||||
- **Latency**: every request from the platform to the workspace traveled through Cloudflare's network — extra hops, extra latency
|
||||
- **Bandwidth costs**: Cloudflare metered tunnel egress; at agent-fleet scale this compounded
|
||||
- **Single dependency**: if Cloudflare had an outage, every agent workspace lost its connection path simultaneously
|
||||
- **No direct diagnostics**: you couldn't `curl` a workspace's IP directly or run network checks without the tunnel path
|
||||
|
||||
For teams running production agent fleets, these weren't hypothetical concerns.
|
||||
|
||||
## What's different now: public IP per workspace
|
||||
|
||||
Phase 33 provisions each workspace with its own public IP address from the VPC's public subnet. The connection model:
|
||||
|
||||
```
|
||||
Your browser / API client
|
||||
│
|
||||
▼
|
||||
Platform API (api.moleculesai.app)
|
||||
│ platform knows workspace IP from provisioning
|
||||
▼
|
||||
AWS security group: platform-controlled inbound rules
|
||||
│ port 443 (WebSocket), authenticated by platform JWT
|
||||
▼
|
||||
Agent workspace — public IP, direct WebSocket
|
||||
```
|
||||
|
||||
The platform still handles auth and routing. But the data path no longer goes through Cloudflare's tunnel network — it's a direct TCP connection from client to workspace.
|
||||
|
||||
What changes for you:
|
||||
|
||||
| | Cloudflare Tunnel (before) | Direct Connect (now) |
|
||||
|---|---|---|
|
||||
| Workspace gets | Cloudflare-assigned hostname | Public IP from your VPC |
|
||||
| Inbound connection | Outbound tunnel WebSocket only | Direct WebSocket on :443 |
|
||||
| Firewall config | None required | Security group rules managed by platform |
|
||||
| Latency | Extra Cloudflare hop | Direct — ~20–40ms reduction depending on region |
|
||||
| Platform dependency | Cloudflare required for connectivity | Platform API still required for auth/routing; workspace IP works for direct curl |
|
||||
| Debugging | Must go through tunnel | `curl https://<workspace-ip>` works directly |
|
||||
|
||||
## What operators need to do
|
||||
|
||||
If you already have a CP-managed workspace in your AWS account (provisioned via the `controlplane` backend with `MOLECULE_ORG_ID` set), Phase 33 transitions automatically. The platform manages the security group rules, so no manual changes are required.
|
||||
|
||||
**New provisioners:** when you create a CP-managed workspace, the platform now assigns a public IP from the workspace subnet. This is automatic — the provisioning flow is the same, just with a different network configuration on the backend.
|
||||
|
||||
**Existing self-hosted or Fly.io workspaces:** no change. Those backends don't use the CP provisioner path and were never on Cloudflare Tunnel in the same way.
|
||||
|
||||
**If you have a custom VPC configuration:** the platform expects a workspace subnet with outbound internet access (for `pip install`, model API calls, etc.) and a security group that the platform can manage. If you've locked down your security groups to deny all inbound from the platform's IP ranges, you may need to allow port 443 from the platform CIDR. Check `docs.molecule.ai/infra/network-requirements` for the current allowlist.
|
||||
|
||||
## What developers need to know
|
||||
|
||||
From an agent runtime perspective — nothing changes. Your code talks to the platform API, registers workspaces, receives task dispatch, and runs tools. The transport layer is different but the API contract is identical.
|
||||
|
||||
Specific things that do change:
|
||||
|
||||
- **Direct workspace access**: if your code or tooling needs to reach a running workspace directly (for monitoring, log scraping, port-forwarding), you can now use its public IP instead of going through the platform proxy
|
||||
- **WebSocket path**: the workspace still opens a WebSocket to the platform on boot. That connection is now outbound from the workspace's public IP to the platform — same direction as before, different path
|
||||
- **CI/CD and health checks**: scripts that hit workspace health endpoints can use the public IP directly; no tunnel hostname required
|
||||
|
||||
## Security model
|
||||
|
||||
The security group rules are managed by the platform, not operator-configured. This is intentional — it means the platform can enforce:
|
||||
|
||||
- Port 443 only (no other inbound ports)
|
||||
- TLS required on all connections
|
||||
- JWT validation before any workspace data is served
|
||||
|
||||
What it doesn't do: the platform doesn't manage your VPC-level security groups beyond the workspace-specific one. If your VPC has overly restrictive route tables or NAT-only egress for the workspace subnet, model API calls from the agent may fail. Ensure your workspace subnet has both inbound 443 from the platform and outbound 443/443 to model provider endpoints.
|
||||
|
||||
## When this ships
|
||||
|
||||
Phase 33 is rolling out to all new CP-managed workspace provisions starting 2026-04-22. Existing workspaces will migrate on their next restart cycle — the platform handles this automatically during normal workspace rotation.
|
||||
|
||||
If you have questions or hit issues during migration, the runbook is at `docs.molecule.ai/infra/cloudflare-tunnel-migration`.
|
||||
|
||||
---
|
||||
|
||||
*Phase 33 is part of the Molecule AI infrastructure hardening track. For the full roadmap, see `docs.molecule.ai/roadmap`.*
|
||||
@ -0,0 +1,148 @@
|
||||
# EC2 Instance Connect SSH — Social Copy
|
||||
Campaign: ec2-instance-connect-ssh | PR: molecule-core#1533
|
||||
Publish day: 2026-04-22 (today)
|
||||
Assets: `marketing/devrel/campaigns/ec2-instance-connect-ssh/assets/`
|
||||
Status: Draft — pending Marketing Lead approval + credential availability
|
||||
|
||||
---
|
||||
|
||||
## X (Twitter) — Primary thread (5 posts)
|
||||
|
||||
### Post 1 — Hook
|
||||
|
||||
> Your AI agent has a workspace on an EC2 instance.
|
||||
>
|
||||
> How do you get a shell inside it right now?
|
||||
>
|
||||
> Old answer: copy the IP, find the key, `ssh -i key.pem ec2-user@X.X.X.X`, hope your
|
||||
> security group is right.
|
||||
>
|
||||
> New answer: click Terminal in Canvas.
|
||||
>
|
||||
> Molecule AI now speaks AWS EC2 Instance Connect.
|
||||
|
||||
---
|
||||
|
||||
### Post 2 — The problem it solves
|
||||
|
||||
> SSH into a cloud agent workspace sounds simple.
|
||||
>
|
||||
> It's not.
|
||||
>
|
||||
> → Instance IP changes on restart
|
||||
> → Key management across your whole agent fleet
|
||||
> → Security group rules you have to get right every time
|
||||
> → No audit trail on who SSH'd in and when
|
||||
>
|
||||
> EC2 Instance Connect handles all of it. Molecule AI wires it up so
|
||||
> your agent workspace is one Terminal tab away.
|
||||
|
||||
---
|
||||
|
||||
### Post 3 — How it works
|
||||
|
||||
> Molecule AI + EC2 Instance Connect:
|
||||
>
|
||||
> → Workspace provisioned in your VPC, instance_id stored
|
||||
> → Click Terminal tab in Canvas → WebSocket opens
|
||||
> → Platform calls `aws ec2-instance-connect ssh` under the hood
|
||||
> → EIC Endpoint opens a tunnel, STS pushes a temporary key
|
||||
> → PTY bridges directly to the Canvas terminal
|
||||
>
|
||||
> No keys to manage. No IP to find. No security group dance.
|
||||
> One click.
|
||||
|
||||
---
|
||||
|
||||
### Post 4 — Security angle
|
||||
|
||||
> Every SSH access to a cloud agent workspace should be attributable.
|
||||
>
|
||||
> With EC2 Instance Connect:
|
||||
>
|
||||
> → IAM policy gates access (condition: `Role=workspace` tag)
|
||||
> → STS temporary key, auto-expires
|
||||
> → EIC audit log shows which principal requested the tunnel
|
||||
> → No long-lived SSH keys anywhere
|
||||
>
|
||||
> Your security team will appreciate this.
|
||||
|
||||
---
|
||||
|
||||
### Post 5 — CTA
|
||||
|
||||
> EC2 Instance Connect SSH is live in Molecule AI (PR #1533).
|
||||
>
|
||||
> Provision a CP-managed workspace → open the Terminal tab → you're in.
|
||||
>
|
||||
> If you're still `ssh -i key.pem` into your agent fleet — there's a better way.
|
||||
>
|
||||
> [CTA: docs.molecule.ai/infra/workspace-terminal — pending docs publish]
|
||||
> #AgenticAI #MoleculeAI #AWS #DevOps #PlatformEngineering
|
||||
|
||||
---
|
||||
|
||||
## LinkedIn — Single post
|
||||
|
||||
**Title:** We gave AI agents their own terminal tab — powered by AWS EC2 Instance Connect
|
||||
|
||||
**Body:**
|
||||
|
||||
Getting a shell inside a cloud-hosted AI agent used to mean: find the instance IP, locate the SSH key, configure the security group, run `ssh`, hope nothing broke.
|
||||
|
||||
That's now one click inside Molecule AI.
|
||||
|
||||
We shipped EC2 Instance Connect SSH integration (PR #1533). Here's what changed:
|
||||
|
||||
**The old flow:**
|
||||
Copy the EC2 IP → find the SSH key → configure the security group to allow port 22 → `ssh -i key.pem ec2-user@X.X.X.X` → verify you're connected
|
||||
|
||||
**The new flow:**
|
||||
Provision a workspace in Canvas → click Terminal → you have a bash prompt
|
||||
|
||||
What makes this possible is AWS EC2 Instance Connect. The platform stores the `instance_id` from provisioning, calls `aws ec2-instance-connect ssh --connection-type eice` on your behalf, and the EIC Endpoint opens a tunnel with an STS-pushed temporary key. The PTY bridges straight into the Canvas Terminal tab.
|
||||
|
||||
Why this matters beyond convenience:
|
||||
|
||||
→ No long-lived SSH keys to manage or rotate
|
||||
→ IAM policy controls access (condition on `aws:ResourceTag/Role=workspace`)
|
||||
→ EIC audit log gives you provenance on every tunnel open event
|
||||
→ Temporary keys auto-expire
|
||||
|
||||
Your agent workspaces are now as easy to access as your browser tab — with better audit trails than a manually managed SSH key rotation process.
|
||||
|
||||
EC2 Instance Connect SSH is live now for all CP-provisioned workspaces.
|
||||
|
||||
---
|
||||
|
||||
## Visual Asset Specifications
|
||||
|
||||
1. **Terminal demo GIF** — Canvas Terminal tab showing bash prompt inside an EC2 workspace:
|
||||
- Canvas UI with a workspace node selected
|
||||
- Terminal tab open, showing `ec2-user@ip-10-0-x-x:~$` prompt
|
||||
- Optional: running `whoami` or `hostname` to show EC2 context
|
||||
- Format: GIF or looping MP4, max 10s
|
||||
- Dark theme, molecule navy background
|
||||
|
||||
2. **Architecture diagram** (optional for LI):
|
||||
- Canvas (browser) → WebSocket → Platform (Go) → `aws ec2-instance-connect ssh` → EIC Endpoint → EC2 Instance
|
||||
- Shows the tunnel path for audience who wants to understand the mechanism
|
||||
|
||||
---
|
||||
|
||||
## Campaign notes
|
||||
|
||||
**Audience:** DevOps, platform engineers, ML infrastructure teams running agents in AWS
|
||||
**Tone:** Practical — the IAM/audit story is the differentiator for security-conscious buyers; the "one click" story is the differentiator for developer audience
|
||||
**Differentiation:** No manual SSH key management vs. traditional bastion host approach
|
||||
**Hashtags:** #AgenticAI #MoleculeAI #AWS #EC2InstanceConnect #PlatformEngineering #DevOps
|
||||
**CTA links:** docs pending (workspace-terminal.md docs need to be published)
|
||||
|
||||
---
|
||||
|
||||
## Self-review applied
|
||||
|
||||
- No timeline claims ("today", "just shipped", etc.) beyond what's confirmed in PR state
|
||||
- No person names
|
||||
- No benchmarks or performance claims
|
||||
- CTA links marked as pending until docs confirm live
|
||||
Loading…
Reference in New Issue
Block a user