Bring a workload. Define the boundary.

01 / Runtime scope

One Linux environment for the run.

The initial plan covers environment creation, command execution, stopping and snapshots through an API, SDK and CLI. Root access, Docker support and SSH are launch requirements to validate with the selected runtime.

There is no Ithaca SDK package, install command, hosted API endpoint or self-service provisioning available today. We will publish executable quickstarts with the implemented interface.

• Linux CPU workloads first.
• VM size, startup time, concurrency and persistence limits to be measured.
• GPUs, Windows, macOS and desktop streaming outside the initial scope.

02 / Approval boundary

Separate the machine from its authority.

Agents run inside an isolated environment. Privileged access to production systems should pass through a trusted executor that checks identity, policy and any required approval. Giving an agent root inside its own VM must not grant it the executor’s credentials.

Remus is the permissions layer being developed for this boundary. Its available local preview exercises allow, deny and approval against fixture tools. It is not yet integrated with an Ithaca compute service.

Slack approvals, email approvals and a hosted review dashboard are not confirmed launch features. We will define the supported review path during pilot planning.

03 / Deployment & data

Make the location and limits explicit.

A UK region is planned. The provider, isolation runtime, VM storage, log storage, backups, retention and support access must be confirmed before customer workloads are accepted.

UK data residency is not currently available as an Ithaca service commitment. No security certification, SLA or benchmark is claimed.

Run records should connect the requesting identity, environment, protected action, approval and outcome. Command and file-change capture require a separately validated logging design; this page does not promise complete capture.

04 / Pilot evaluation

Prove the path before expanding access.

1. Choose one workload and list every system and credential it needs.
2. Define which actions can run automatically and which require review.
3. Agree the region, data classification, retention and isolation requirements.
4. Test allowed actions, denials, expired approvals and direct-access bypass attempts.
5. Measure setup time, execution cost and the record needed to investigate a run.

Romulus’s local recovery preview can be evaluated independently. Snapshot support and workflow recovery are separate concerns; a VM snapshot alone does not make external writes safe to repeat.