Security & data residency

For a product built to run code you can't trust, the most important question is: how is it contained?

Isolation & security

Each run is its own machine

Every session on inis.run gets a dedicated hardware-isolated environment — a clean slate, not a shared container. There is no way for code running in one session to read memory, files, or network traffic from another session. The boundary is enforced in hardware, not software.

When a session ends, its memory and disk are destroyed. Nothing persists unless you explicitly asked for it to — a checkpoint, a template, a captured artifact, or an attached volume.

Network egress is controlled

Outbound network access from inside a session is controlled via an allowlist you can turn on per project (or per session). By default a session has full public egress; set a project — or your whole org — to deny-by-default and its sessions are restricted to an explicit allowlist instead. Either way, attempts to reach destinations outside an active allowlist are blocked at the network layer — not by the guest OS, which your code controls. While an allowlist is active, outbound attempts are logged, allowed and denied alike. A session left on the default full-egress policy is not filtered, and its outbound traffic is not recorded in the execution log at all — network logging is a property of running under an allowlist, not something that happens to every session. See Networking & egress for the full policy model and Execution log for how to read the logged events back.

This means untrusted code running inside a locked-down session cannot use inis.run as a launchpad for outbound attacks or exfiltrate data to arbitrary destinations.

One kernel per session

Every session gets its own VM with its own kernel and its own memory — the boundary is enforced by the CPU, not by a shared kernel. Sessions belonging to different customers can be scheduled onto the same machine; what separates them is that virtualisation boundary, not physical separation. Each session also gets a flat outbound bandwidth cap, so one workload cannot starve another's network.

We do not inspect your code or data

inis.run does not store, log, or inspect the code you run or the data processed inside your sessions. We collect only the operational metadata needed to bill you and keep the service running: session duration, resource allocation size, and API request rates. See our Privacy Policy for the full picture.

The one exception is opt-in: if you configure a Connection to inject a credential into requests your session makes to a specific origin, the platform terminates TLS on requests to that one bound origin so it can check the request and inject the credential — that's how the credential gets attached without your code ever holding it. Every other destination is passed through untouched; nothing outside the origins you've explicitly bound is ever decrypted.

Abuse & misuse

inis.run is infrastructure for legitimate code execution. We do not permit its use for generating malware, launching attacks, distributing illegal content, or circumventing other platforms' security controls.

If you encounter misuse — of our API, our preview URL infrastructure, or anything running on our platform — report it to abuse@inis.run. We investigate every report and act on confirmed violations promptly, up to and including immediate account termination and cooperation with law enforcement where required.

For security vulnerabilities in inis.run itself, see our Security Policy.

Data residency & EU ownership

EU-owned, EU infrastructure

inis.run is Irish-owned and run from Ireland. Our infrastructure runs on bare-metal hardware hosted in the EU. Both our hosting provider and inis.run itself are genuinely EU-owned — there is no US parent company in the data path.

Your workload data — the code you run, your files, your session contents — never leaves the EU, and neither does anything derived from it: the databases, operational logs, and stored session, checkpoint, and template state behind the service all sit on EU infrastructure.

Account and billing metadata is the exception, and the sub-processor list is the authoritative record of it: optional GitHub or Google sign-in and Stripe payments go through the providers named there, each with its processing location.

Why ownership matters — the CLOUD Act

The US CLOUD Act lets US authorities compel a US-owned company to hand over data stored anywhere in the world, including on servers physically located in the EU — so where a provider's data centres sit is not the deciding factor, ownership is. inis.run is EU-owned with no US parent, so a valid EU legal process is required to access any data we hold.

What we don't claim

We do not claim to be a compliance product. inis.run is execution infrastructure. Whether it meets your specific compliance requirements — GDPR processor obligations, sector-specific rules, internal data governance policies — is your call to make. We give you the facts; you decide whether they fit.

If you need specifics for a procurement or legal review, write to hello@inis.run.

---

General questions: hello@inis.run — abuse reports: abuse@inis.run — security vulnerabilities: security@inis.run