cloudflare
Surface log stream from sandboxed app
I think the sandbox is currently the biggest weak link of the project. In some chats the preview boots up, in a lot of them it does not for me. Blueprint, code generation seems stable enough, but the preview fails in most cases for me and often it's not recoverable.
It would be great to have a full log stream from the sandbox in UI. To see if the server started remotely, on what port, if there's any issues. See the results from bun install and then bun run dev.
It would be a boost to the UX, better than seeing Retrying preview 8 / 10.
Thank you for raising the issue. Had been quite busy this week so couldn't take much look into the sandbox related bugs - Had released major changes to the sandbox layer since the past week. If you are having issues, can you share more context/details around it, like how often does it happen, for which apps (if consistently), and what websocket messages do you get upon failure etc? Because, anything other than a perfectly functional preview is a bug that needs to be fixed.
Sometimes I am getting
502 Bad Gateway
Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared
When I'm visiting the tunnelURL.
It seems to me that this might be connected to:
❌ Error during deployment: Deployment timed out after 60 seconds
At least it seems like in some deployments where I get the preview successfuly the deployment is under 60 secs. And then even changes + re-deploy works well.
Sometimes I see multiple tunnel URLs in the logs:
{"level":"info","time":"2025-10-30T14:14:39.882Z","component":"SandboxSdkClient","msg":"Found cloudflared tunnel URL: https://mysterious-accepts-jewellery-habitat.trycloudflare.com","object":{"type":"SandboxSdkClient"},"sandboxId":"aed9f762-54f2-48cd-8177-6570a5a4a475","agentId":"be8a422f-f844-4d79-8557-0da2600d0d8c"}
{"level":"info","time":"2025-10-30T14:14:45.779Z","component":"SandboxSdkClient","msg":"Cloudflared log ===> 2025-10-30T14:14:45Z INF +--------------------------------------------------------------------------------------------+\n2025-10-30T14:14:45Z INF | Your quick Tunnel has been created! Visit it at (it may take some time to be reachable): |\n2025-10-30T14:14:45Z INF | https://dropped-oklahoma-dawn-manner.trycloudflare.com |\n2025-10-30T14:14:45Z INF +--------------------------------------------------------------------------------------------+\n","object":{"type":"SandboxSdkClient"},"sandboxId":"aed9f762-54f2-48cd-8177-6570a5a4a475","agentId":"be8a422f-f844-4d79-8557-0da2600d0d8c"}
{"level":"info","time":"2025-10-30T14:14:45.779Z","component":"SandboxSdkClient","msg":"Found cloudflared tunnel URL: https://dropped-oklahoma-dawn-manner.trycloudflare.com","object":{"type":"SandboxSdkClient"},"sandboxId":"aed9f762-54f2-48cd-8177-6570a5a4a475","agentId":"be8a422f-f844-4d79-8557-0da2600d0d8c"}
{"level":"warn","time":"2025-10-30T14:15:37.216Z","component":"CodeGeneratorAgent","msg":"Deployment timed out after 60 seconds, resetting sessionId to provision new sandbox instance","object":{"type":"CodeGeneratorAgent","id":"be8a422f-f844-4d79-8557-0da2600d0d8c"},"sessionId":"e954ccf2-973e-4eac-b241-66e5f2cab123","agentId":"be8a422f-f844-4d79-8557-0da2600d0d8c","userId":"10bbdad5-d9d2-4c62-8b79-096ab09620ed"}
It seems like if the connection to the sandbox is not established well in the beginning, then the retries don't help.
I need to copy the prompt and try again from the beginning.
Interesting. I did observe that deployments were timing out quite often after a previous release. I did find and fixed a few bugs in the deployment flow, but didn't quite find the bandwidth to validate it. Can you, in the meantime try pulling the latest from the nightly branch and test it out?
Also, the tunnel urls are generated for local development, but cloudflared tunnels aren't officially meant for this purpose (they would give all sorts of disclaimers in the logs too). Its kind of a hack until we have better localhost support.
Its worthwhile investigating the deployment timeouts. Is this on localhost? If latest changes from nightly don't fix it for you, maybe we can try debugging your deployment over a call on discord?
ok! I'll try to rebase on nightly, it's a bit difficult since I already forked the project to change react prompting to vitepress prompting (I can have a vitepress template but there would still be a LOT of input tokens used to teach the LLM how to prevent React pitfalls).
also unfortunately I had some large file changes due to indentation changes, might be a problem on my side, but maybe explicit ESLINT / prettier config would prevent that
will report if I'm successful
Also, the tunnel urls are generated for local development, but cloudflared tunnels aren't officially meant for this purpose (they would give all sorts of disclaimers in the logs too). Its kind of a hack until we have better localhost support.
That sounds great, if the preview app ran locally in some subprocess maybe all errors and current state could be investigated easier
Yeah, the rebase might be touch. Have a look at the changes in the current latest and your branch, and maybe cherry pick commits?
The preview apps do run locally - if you are doing local development, it must be using docker to do it, and thus you can simply open docker desktop (or cli) and connect to your running containers and check the logs, preview app files etc. Thats how I debug as well. The tunnels are just because ports can't be exposed on a docker container after it has been started.
ah, that's good to know, I will try to explore around in Docker too, thanks 🙏️
Hi @AshishKumar4 , I just ran nightly branch, without my vitepress changes and it's the same thing, in most cases the preview gets stuck on
502 Bad Gateway
Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared
I'm trying to look around in Docker, so far I could just reach minimal logs and no errors there but I'm trying to look deeeper into it
on Docker side I have three containers running side by side, but there seem to be workspaces with instances in them
It mostly is because for local dev, we use cloudflared tunnels, which is really not a recommended way. This shouldn't persist though. For faster resolution, I can help you over the discord in a screenshare session, if you were to create a thread in the vibesdk channel in Cloudflare dev discord server