Cloudflare to Sprite SSL/TLS is broken, preventing custom domains, therefore prod use cases

Questions / Help
,
1

Hi all :waving_hand:

I’m a big fan of sprites. They map incredibly well into my workflow for remote agentic development. In fact, I wrote a little wrapper called seven* that gives me my beloved vagrant-like workflow, but with remote microVMs. sprite + vagrant up = seven up. Get it?

This works mostly really well (although I’d love a way to reuse a snapshot across multiple sprites, to facilitate parallel codex / cc sessions).

Today I wanted to take this process to its natural conclusion, as pointed out by @mrkurt in his announcement blog post ( Code And Let Live · The Fly Blog ): instead of coding on the sprite then running prod elsewhere, why not run the app on the sprite? At least for most internal apps, this is the lowest possible friction from vibe-coding new features to making them available to users.

Except… I don’t think this works yet? Sprites don’t have custom domains and certs the way regular Fly VMs do. And as far as I can tell, it’s also not possible to proxy from Cloudflare to a sprite’s public URL.

Root cause: the Fly proxy in front of the Sprite only terminates TLS for *.sprites.app. Connections arriving with SNI mydomain are rejected at the TLS layer. There’s no fly certs add
equivalent for Sprites, and the Sprites CLI/dashboard has no custom domain configuration.

So unless I’m missing something, for now we’re back to deploying on full-on VMs and/or Vercel. Thoughts?

Prior research:

2

I’ve not tried this, so take with as much salt as you need. But could you set up your own proxy in a Fly app, and then carry connections from the proxy to the sprite? I appreciate that the TLS encryption/decryption is done twice, but it might not matter in your case.

3

Your solution would definitely work… but at that point I might as well run the entire stack in the Fly app instead. Which is what I ended up doing. I’ll revisit if/when sprites get custom domains/certs.

1 Like