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.

Thanks for the details!

Do you think there could be ways for someone to abuse the network setup you have?

For example, accessing other internet hosts or other containers in the same container network?

What happens when curl gets redirect responses?

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!

Hey that is weird, can you file a bug report here with the curl you were trying?

https://github.com/uncurl/uncurl-support

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.)