How OnlineCompiler.io runs code it has never seen

Each run gets its own sandbox

A run starts a new container, executes the program and removes the container. Nothing is reused between runs, so one program cannot leave files or processes behind for the next.

• gVisor: containers run under gVisor (runsc), which handles the program's system calls in a user-space kernel instead of passing them to the host's kernel. There is no fallback: if gVisor is unavailable, the run fails rather than starting in a less isolated runtime.
• No network: networking is disabled, so programs cannot reach the internet, our servers or yours.
• No privileges: programs run as an unprivileged user (uid 65534) with every Linux capability dropped and privilege escalation turned off.
• Read-only filesystem: the language image is read-only. The only writable space is a 256 MB workspace and 128 MB for temporary files, both held in memory and mounted without setuid or device files. The code and stdin are mounted read-only from a private directory created for that job.
• Fixed limits: 512 MB of memory with no swap, 2 CPUs, 64 processes, 256 open files and no core dumps. After 30 seconds the program is stopped, and the container is killed if it doesn't exit.
• Bounded output: up to 64 KB per stream is kept, and a program that prints more than 8 MB is stopped, so a flood can't exhaust our workers.

The full list of limits, and the exit codes a run returns when it hits one, is in the API docs.

Keys and accounts

• Two kinds of key. API keys call the REST API and the MCP server and belong on your server. Widget keys are meant for public pages: they only work over the widget's WebSocket, cannot call the REST API, and can be restricted to your domain, which we check on every connection. An iframe embed with a restricted key can only be framed by pages on that domain.
• Account limits contain a leaked key. Every account has a per-minute rate (30 runs by default), a cap on pending runs (8), a cap on runs in a sandbox at once (2, so one account can't take every sandbox) and a monthly allowance, shared by all its keys. Disable a key in the dashboard to cut it off.
• Callbacks only go to public addresses. The async endpoint posts results to the HTTP or HTTPS URL on your API key. Private, loopback and link-local addresses are refused, redirects are not followed, and the address is checked again at delivery so a DNS change can't point it inside our network.
• Encrypted in transit. The API and WebSocket are served over HTTPS and WSS; plain HTTP requests are redirected.

What we store

Each run is stored as execution history: the code, input, output, errors, exit code, timing, the key that sent it and the client's IP address. You can see your account's history in the dashboard. How long it is kept, and how to have it deleted, is in the Privacy Policy. Programs themselves can't store anything: their workspace disappears with the container.

What we don't claim

• We don't hold SOC 2 or ISO 27001 certification, and we haven't published a third-party audit.
• No sandbox is perfect. gVisor shrinks the part of the kernel a program can reach, and the limits above contain what it can do, but neither is a guarantee.
• OnlineCompiler.io is hosted only. If your policy requires code to run on your own servers, this isn't the right fit.

Reporting a vulnerability

If you find a way out of the sandbox, around a limit, or into another account's data, please contact us with the steps to reproduce it before disclosing it publicly. Test against your own account only, and don't degrade the service for other users.

Frequently asked questions

Is it safe to run untrusted code with OnlineCompiler.io?

That is what it is built for. Every run gets a new container under gVisor, with no network, an unprivileged user, a read-only filesystem and fixed limits (512 MB of memory, 2 CPUs, 64 processes, 30 seconds). The code runs on our servers, never on yours.

Can code in the sandbox reach the internet or my servers?

No. Containers start with networking disabled, so programs cannot open connections, download packages or call back to your systems. Results reach you only through our API.

Can one user's code see another user's?

Each run gets its own container with its own memory-backed workspace, and its code and input are mounted read-only from a private directory for that job. The container is removed when the run ends, so nothing carries over to the next run.

Is the widget key a secret?

No. Widget keys sit in public HTML by design. They only work over the WebSocket the widget uses, cannot call the REST API, and can be locked to your domain. Keep REST API keys on your server.

Do you keep the code that runs?

Yes. Each run is stored with its input, output and timing as execution history, which you can see in your dashboard. The Privacy Policy covers how long it is kept; ask us to delete your account and its data at any time.