darubramha

You can delete the curl request if created from a logged in account.

Non-logged in curls are auto purged after 30 days.

The sandbox is a lightweight Alpine-based container, it runs as a non-root user for security, it has minimal dependencies installed (curl, bash, coreutils)

The container has restricted outbound access—only HTTP/S requests are allowed. It runs inside an isolated network namespace with no access to the host network or other infrastructure components. There's no inbound access, and the container can't receive unsolicited requests from the outside world.

The sandbox container can only communicate with other containers in the same network, the main application container and sandbox container are on the same network, allowing them to communicate.

Yes — executions are done server-side, inside a resource-limited, sandboxed Docker container. That’s why login is required: to prevent abuse, rate-limit usage.

I have a feature working to allow users browser side execution, but as others have also pointed out CORS is a big blocker for client side execution not working for all APIs.

Hey, you can absolutely delete any curls created if done from a logged in user, for others it will get auto-purged in 30 days of non-usage.

You didn’t miss anything in the docs. Right now uncurl.dev only supports http/https (and technically ftp, though it’s untested). Protocols like dict://, smtp://, etc. aren’t parsed or handled correctly yet, which is why you’re seeing that “invalid URL” error.

I hadn’t actually considered dict:// usage, I see the bug report as well, thanks, will see if I can include it.

:) the curl command parser expects some flags of GET, POST, stupidly overlooked, will get it fixed!

Haha love that you shared the curl with the uncurl.dev url!

Yes, delete is unauthenticated as highlighted, will be working on a fix for this. And you can delete any API if it is created as a logged in user.

I have implemented auto-purge all curls that are created without login will get auto deleted after 30 days of non-usage.

You can absolutely delete your curl if you have created as a logged in user.

Appreciate the kind words—and the comparison!

uncurl.dev kind of grew out of that same spirit, but with the goal of making the output shareable and executable in a browser, especially for folks who might not have an IDE set up or are outside the usual dev loop (PMs, etc.)

Fair. I appreciate the honesty — even if it's a bit brutal :)

Security is a top priority for this project, and I'm actively working to tighten things up. This initial version was launched to validate the concept, and admittedly, there were oversights (including an unauthenticated DELETE endpoint that was highlighted).

If you're open to it, I'd love to learn more about what you'd want to see from a security standpoint in a tool like this. I'm building in public and happy to be corrected where needed.

Thanks again for keeping things real.

Exactly — this was one of the core constraints I ran into early on.

CORS was a blocker for client side requests, I have a separate branch where this is integrated, maybe will add it alongside server side execution to let the person creating the curl decide whether they can execute on browser or server side.

Totally with you on that—your use case is exactly what I had in mind when I built uncurl.dev.

I kept finding myself sending curl requests in Slack or email, and it felt clunky—especially when non-devs or support teams needed to test something quickly. uncurl.dev started as a way to make that share-and-execute process more visual and frictionless.

For the auth part—embedding API keys in payload is a no-go in most cases. For now, sending out auth headers separately for them to fill in themselves is what I did within my workplace.

I'm exploring a couple of ideas to help with this:

Team-scoped secrets: For logged-in users or teams, saving common auth headers that aren’t part of the shared link.

One-time, encrypted secrets: The link works once and destroys the sensitive payload after execution.