We’re building Ever Works in public. Some things may be incomplete, missing, or broken while we continue improving the platform.We’re building Ever Works in public — expect a few rough edges.
Control & safety · Runtime isolation
An agent is only as safe as the box it runs in. Ever Works makes that box something you write down: an Environment says which packages exist and which hosts are reachable, a workspace gives every Task its own branch and checkout, credentials stay as pointers into the secret store you already operate, and the external servers and repositories an Agent may touch are registries you curate — not a default it inherits.
Each one is a separate setting with a separate default, so you can tighten the one that matters without rewriting everything else.
Settings → Environments is where you write a runtime recipe: a name, the pip and npm packages that must be present, and a networking mode — Unrestricted, or Limited to the hosts you list, with a toggle that keeps package registries reachable anyway. The table shows Name, Networking, Status and Updated, and every row stays a draft until you publish it.
Credentials stay where you already keep them. The platform stores a pointer — vault:, k8s:, doppler:, infisical:, or the built-in env: and inline: schemes — and resolves it at run time through one of seven bundled resolver plugins: HashiCorp Vault, Kubernetes Secrets, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, Doppler and Infisical.
A workspace plugin gives every Task its own branch and its own checkout. The sandboxed workspace is the default: it provisions the branch fetch-first, commits and pushes at the end, and simulates the merge in memory so conflicting paths are named before a pull request exists. The local workspace plugin does the same with a real git worktree pool when runs happen on machines you own.
Open a Work → Deploy → Environment variables to set the per-site settings the deployed site reads from process.env — today the Stripe payment configuration. Only allow-listed keys are accepted, values are encrypted at rest and shown back masked, and they reach the site on the next deploy: merged into the Kubernetes runtime Secret on managed deploys, or pushed as GitHub Actions repo secrets on workflow deploys.
Settings → Connections is the workspace-wide registry of external MCP servers. Give one a name, a URL and a transport — Streamable HTTP, or legacy SSE — press Test to connect and see how many tools it exposes, then decide per Agent which servers it may use: connections are inherited by default, and an Agent-level switch narrows that inheritance.
Settings → Repositories holds repositories your Agents can be granted access to independently of any Work: URL, mount path under /workspace, default branch, and a credential key that is Inherited, a GitHub App installation, or a secret reference. Import one from a GitHub App installation in a click, attach it to an Agent, and give that Agent an Init Script that runs at workspace bootstrap.
Four screens, once. After that every run of that Agent starts from the same place.
Settings → Environments → New environment. Name it, list one pip requirement and one npm package spec per line, and choose Unrestricted networking or Limited with the hosts you allow — one host per line, a single leading *. wildcard permitted.
Save draft while you are still iterating; press Save & publish, or Publish on the row, once it is ready. Only published Environments can be assigned, so a half-written recipe never reaches a run.
Open the Agent’s Capabilities tab and pick the Environment. The picker lists your published Environments and nothing else; leave it on None (default) and that Agent runs exactly as it did before Environments existed.
At dispatch the runtime resolves the Agent’s published Environment and carries it into the run, so the toolchain and the egress rules are the same every time. Deleting an Environment an Agent still uses is refused rather than silently unassigned.
Every surface on this page is built so the platform database is not where your credentials end up. A repository registry entry records where a credential lives, never the credential itself; an MCP connection returns the names of its auth headers and never their values; a per-Work variable comes back masked, and a secret one comes back as three asterisks. The rule holds even for the things you type in yourself.
Environments, MCP Connections and the repository registry are complete in the dashboard: create, publish, assign, test, import. Secret stores are further back. The seven resolver plugins ship in every image and are wired into the job-runtime credential path — where a self-hosted install resolves its own background-job credentials — but choosing which resolver runs is operator configuration today rather than a screen in the product, and broader credential brokering across Agents and Works is still being built. Resolution deliberately fails open: an unreachable store logs a warning and falls back to the instance default instead of stopping your work.
Decide which agent actions run on their own, which wait for a human, and how much any of it may spend — then approve from the dashboard or the Inbox.
Learn more →Named AI employees — a CEO, a CTO, a Researcher — that run your Missions, Ideas, and Works around the clock.
Learn more →Where a Work deploys, where the platform itself runs, which engine executes background work, and where uploads, data and vectors live — each one a plugin you pick.
Learn more →A plugin is a capability the platform does not have on its own — a model, a search engine, a Git host, a deploy target — and Ever Works ships 102 of them.
Learn more →Turn any machine into an execution node with Ever Works Node, and see every node — including your own Kubernetes nodes — in one Fleet view.
Learn more →Describe what you want to build. Ever Works researches it, ships it, and keeps it improving — content and code, owned in your own Git.