How do I expose my sprite as a url?

Questions / Help
1

I have tried to play around with a sprite that exposes an http server, but I am not able to connect to it from my local machine. I tried using the sprite url command, but I cannot seem to expose it. Doesn’t it need to be on a specific port? I know I can do it via port forwarding, but curious how the sprite url command is working.

2

Yeh I think you need to be serving on 8080 right now. We’re looking at ways to expose other ports soon, but haven’t shipped anything for that yet.

3 Likes
3

We need to be able to expose other ports for our use case. @jfent do you have an estimate of time? Happy to test early and help debug/develop it.

4

What’s your use case?

1 Like
5

We use sprites as remote web development boxes. Being able to expose more ports publicly will allow us to preview the local dev server in real time.

6

Preview on your own local machine? There’s sprite proxy for proxying a Sprite’s port to your local machine. E.g. if you have a dev server running on the sprite on port 1234, you can do sprite proxy -s SPRITE_NAME 1234 and then http://localhost:1234 on your local machine will be proxied to the sprite’s port 1234 (you can use local:remote syntax if you want to proxy a local port to a different remote port)

You can also sprite proxy <port_config_a> <port_config_b, i.e. you can setup multiple port proxies in the same command

1 Like
7

No, I mean, for example, a pnpm dev for a nextjs app running inside of a sprite. We are talking to an agent that lives in a sprite and is building the nextjs app, but we want to be able to see what the sprite local dev server is outputting in real time. We are communicating with the agent via http.

Edit: we are doing all this with the public URL, via http on a deployed webapp elsewhere, no shell access or local machine

8

Nothing here conflicts with using sprite proxy, I’m confused what your setup is.

So the thing that is trying to access the dev server on the Sprite is not itself able to run sprite proxy? The communication looks like below?

[you] <--> [some web app] <--> [sprite]
1 Like
9

Our setup is:

[user browser] <> [our webapp on Vercel] <> [sprite via HTTP API]

Our webapp communicates with sprites purely via the HTTP API (exec, filesystem, etc.). Users view sprites through iframes pointing to the public sprite URL.

We can’t run sprite proxy because:

  • Our app is serverless (Vercel) - no persistent process to run CLI
  • Users are in browsers, not terminals

We need the sprite’s public URL to route to multiple ports (8080 for opencode, 3000 for dev server) so we can show both in iframes side-by-side (agent on one side, web preview on the other side).

Unless I’m missing something, the only (nice) way we can achieve this is with multiple ports.
Happy to clarify further!

10

Gotcha, ok.

sprite proxy is just using this proxy API under the hood, which is intended for doing the thing you’re describing (accessing dev servers on non-8080 ports).

Would it work to make a request to 3000 using that API and render the response in the iframe each time you need to re-render?

1 Like
11

Thanks for sharing the proxy API. I’m looking into it!

That said, direct access to other ports via the public URL would be a much more straightforward solution for our use case (embedding dev server in an iframe alongside the main app).

Are you still planning on adding support for it?

12

It’s not on the roadmap at the moment, we’re nudging people towards that proxy API or else setting up a reverse proxy fly app to multiplex.

1 Like
13

Thanks, I appreciate the transparency

14

Just so I make sure I’m following:

  1. Your app on Vercel
  2. Customer Sprites
  3. Your app uses API to do things in Sprites on behalf of customers
  4. Your app also uses public sprite URL to show them stuff
  5. The local dev server logs to stdout/stderr
  6. You want to show those logs via HTTP to users? Or access them via HTTP for other reasons?

Our general rule of thumb has been “URL for outside access, Sprite API for internal management”. If I’m understanding what you need other ports for, I think we may have a simple option for you already.

1 Like
15

What we have currently (and works nicely).

  1. Customer clicks a button on our app.
  2. We spawn a new sprite via API
  3. The sprite runs OpenCode on port 8080.
  4. We embed it in an iframe via the public sprite URL.
  5. Customer chats with the AI agent direcly in the browser.

What we want:
6. The agent runs pnpm dev which starts a Next.js dev server on port 3000.
7. We want to embed that dev server in a second iframe, side-by-side with OpenCode.
8. User chats with OpenCode on the left, sees their app hot-reloading on the right.

I’m happy to chat or have a quick call and show you the setup.
Curious to know more about the option you mentioned!

16

@kurt curious about that option you mentioned :- )

17

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