Neural Inverse Govern / Cloud workspaces
Development workspaces that start from what you approved and stay inside your policy.
Workspaces built from versioned templates and environments, with egress enforced on the compute host, secrets injected as the person who starts them, and terminals and SSH that never open an inbound port.
- Built from
- Versioned templates and environments
- Runtime
- Linux containers or Firecracker microVMs
- Network
- None, trusted, custom or full
- Access
- Terminal and SSH through a relay
- Compute
- Hosted, your runners, or your AWS or Azure account
Overview
A cloud workspace is a development machine Govern builds from a template your administrators approved, inside a project. An environment adds where it runs, its size, its network access, a setup script, variables and vault references, and who may use it. An agent inside the workspace registers with a signed token that is revoked when the workspace stops, serves terminals and SSH through Govern's relay, and hands git and vault credentials to the person's own user without exposing its token.
What it does
What cloud workspaces provide.
Only what runs today. Partial and planned parts are listed at the end of the page.
Workspace templatesA versioned catalogue of Terraform templates with per-template permissions. Versions are activated or archived, and a deprecated template starts no new workspace.
Workspaces in projectsCreate a workspace in a project from a template, start, stop and rebuild it through the provisioner queue, and list a project's workspaces. Each workspace is checked on its own: use, read, write, secrets and manage.
Cloud environmentsNamed environments fix the compute source, size, template, network access, setup script, variables and vault references. Access is everyone, administrators only, or people granted use; a status computed on the server says whether sessions can start.
Network accessNone, a trusted list of package registries and source hosts, your own domains, or full access. Proxied access goes through an egress proxy that refuses IP literals, private and metadata addresses, DNS rebinding and mismatched TLS server names.
Secrets as the personVault references are resolved when a workspace starts, with the permissions of the person starting it, and delivered through the agent. Variables or setup scripts that look like credentials are refused.
Workspace agentRegisters with a signed, revocable per-workspace token, fetches its manifest and environment, runs startup scripts, checks app health and ships its stats and logs. A workspace whose agent does not connect is reported failed with the reason.
Per-person usersTerminals and SSH never run as root. Each person works as their own Linux user, named by the server; only the owner gets sudo, and only when the template allows it.
Browser terminal and SSHThrough Govern's relay: the agent dials out and listens on no port. SSH authenticates with the member's own keys against a pinned host key; port forwarding reaches loopback only, and sftp and agent forwarding are refused.
Sessions re-checkedOpen terminal and SSH streams are checked every minute and closed when the person's session ends, they leave the organisation or lose the workspace.
Git credentialsA credential helper inside the workspace asks the agent for per-host git tokens. The workspace's own token never leaves the agent process.
Build and agent logsRead and stream each build's provisioner log and the agent's log from the console or the CLI.
Firecracker microVMsOn hosts with KVM, workspaces run in Firecracker microVMs with a read-only template root, a persistent home disk and no inbound network; hosts without KVM run containers.
Your own runnersOnce an Owner or Admin allows it, environments can run on the account's own provisioner runners instead of hosted workers. Jobs for one placement never go to another.
BYOC computeRun provisioner and sandbox workers in your own AWS or Azure account. Govern holds no long-lived key, proves least privilege at setup, and workers reach it only over mTLS with short-lived certificates.
Running hours and quotasRunning time is metered per account, and a start that would pass the quota is refused.
How it works
How a workspace starts.
Every step is decided on the server; the console only shows the result.
- ChooseA member picks an environment or template in a project they belong to.
- CheckGovern checks access to the environment and template, its status and the quota.
- ResolveVault references are resolved as that person and the network policy is compiled.
- BuildA provisioner for the right placement builds the workspace with its egress proxy and setup script.
- ConnectThe agent registers with its token and serves terminals and SSH through the relay.
- RecordThe start, every session and every refusal are in the audit log.
Who uses it
Built for every role that answers for AI.
Platform engineersPublish templates and environments, run provisioner runners and connect cloud accounts.
DevelopersStart workspaces in their projects and work in them through the browser terminal, SSH or the command line.
Security teamsSet network access and who may use each environment, and deny compute sources with policies.
AdministratorsDecide whether accounts may run environments on their own compute, and set defaults per product.
Enforced and recorded
Enforced on the compute host, not in the client.
Network policy, credentials and sessions are decided by Govern and its workers.
Enforced
EgressThe compiled network policy runs on the compute host. A tool that ignores the proxy settings has no network at all, and a worker that cannot apply a policy refuses the session.
Widening needs moreChanging a setup script or widening network access needs manage rights on the environment; narrowing needs only write.
TokensStopping, killing or deleting a workspace revokes its agent token, and every agent route needs the current one.
PlacementHosted, own-runner and BYOC jobs go only to their own workers, and workers from another region are refused.
Recorded
Environment changesChanged fields and variable names, never values, and the setup script's size.
Session startsProduct, compute source, placement, network access and the trusted list version each session ran with.
Terminal and SSH sessionsOpened and closed with duration and why they ended, never the command text. Refusals with their reason.
Self-hostedProvisioners and workspaces run on infrastructure you operate, as part of your installation.
Your cloud accountWith the hosted service, workers can run in your AWS or Azure account, in regions inside the service region's jurisdiction.
Hosted by usHosted workers in the region that serves your account.
Get started
Set it up with the documentation.
What's next
Being built now.
These are in development and not part of the product today.
Automatic start and idle stopStart schedules, stopping idle workspaces and deadlines for hung builds.
Windows and macOS workspacesWhole virtual machines with a terminal, SSH and a remote desktop in the browser, under the same environments and audit.
Snapshots, prebuilds and build cacheWorkspace snapshots and restore points, prebuilt templates and a shared build cache.
GPU workspacesGPU nodes scheduled and allocated to workspaces, with utilisation reporting.
Sharing and app proxySharing a workspace with guests, and reaching the apps and ports a workspace serves through Govern.
Workspace metricsCPU, memory and disk series per workspace in Observe.
More cloudsBYOC workers in Google Cloud.
Talk to our team.
Neural Inverse is available by request. We work with your engineering, security and procurement teams from the first conversation.