Feature Request: Custom Domains for Sprites

,
1

Sprites are beautiful. They’d be even moreso with custom domains. Something like sprite url update --domain subdomain.example.com -s <name> maybe?

2 Likes
2

Something native to the sprite/fly would be awesome, but I’ve been having great success with Cloudflare Tunnels. They also let you limit the access to a single port and put easy OAuth/token restrictions on who can access the services (you don’t need to make the sprite url public, cloudflared will tunnel out on its own).

4

Thanks for the suggestion, I’ll give that a shot.

1 Like
5

Are Cloudflare Tunnels compatible with sprites sleeping when inactive and waking on request (in this case, the request coming from Cloudflare)?

6

Not that I’ve been able to get working. I think the way the tunnel works it doesn’t appear as a network request, and the part of the sprite that needs to respond doesn’t exist at that point.

I’ve been poking the sprite from the CLI before accessing the site, but that’s not actually a solution if you want the site to be available to others.

I’ll probably end up making the sprite public and using normal DNS to get a custom domain.

7

I think Cloudflare is still a good option, just without the Tunnel. But you can have the non-custom-domain sprite URL as the origin server for the custom domain on Cloudflare. Then the question is how much protection do you need from people hitting the sprite directly via its non-custom-domain URL? I think some options are:

  • Don’t worry about it. Let people hit the sprite via its *.sprites.dev URL.
  • Make the sprite public but make its URL hard to guess by giving the sprite a long name when you create it and then keep that name secret.
  • Keep the sprite private, and add a Cloudflare Worker to add an Authorization header to its requests to the sprite URL.
1 Like
8

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.