A governed dev environment for every engineer
Every engineer wants a coding agent in a ready environment. Every security lead wants to know what that agent can install, reach and spend. With Marshal you define the environment once as a stack, and every engineer gets their own space built from it, with your packages, your network rules and your compute sizes already in place.
The result
- A new engineer starts their first space on day one. Claude Code, GitHub and the repo’s toolchain are already there.
- The tools you mark as required stay in every manifest. Nobody can remove them, and nobody adds a host your policy denies.
- Every request, tool call and blocked call from every space lands in one audit log.
- You change the environment by publishing a new stack version. Running spaces keep what they started with, so nobody’s work breaks mid-task.
How it works
An admin installs the packages and builds the Backend Engineering stack for the acme/web team. The stack carries a network policy that denies by default and a short list of allowed compute sizes. Publishing it turns the draft into a fixed version. Auto-seed new members gives each new member a manifest on it when they register, and Push to members gives one to everyone already in the organization. Each engineer starts spaces from their manifest. Every space checks each outbound call against the stack’s rules and writes it to the audit log.
What you use
| Piece | Its role here |
|---|---|
| Marketplace packages | The agent, the tools and the toolchains in the environment. |
| Manifests and stacks | The stack is the governed baseline. Each engineer’s manifest sits on one version of it. |
| Network policy | The addresses spaces can reach. Admin deny rules always win. |
| Compute sizes | The sizes the stack allows, and its default. |
| Owners, teams and scope | Who can use and change the stack, the manifests and the credentials. |
| Spaces | Each engineer’s own environment, with idle auto-stop. |
| Audit log and Admin dashboards | What every space did, and the network posture across the organization. |
Build it
- Install
claude-code,githuband your toolchain, for examplenode, from Marketplace. See Marketplace packages. - Open Stacks, select New stack, and add the packages. Set Presence to
requiredfor the ones every engineer must keep. See Build and publish a stack. - Under Network, pick the policy for the stack. Add deny rules for hosts you never want reached. See Network policy.
- Under Compute, choose the sizes engineers may pick, and the default. See Compute sizes.
- Publish the first version with Publish v1.
- In Automation, turn on Auto-seed new members. Then open More stack actions and choose Push to members. See Give the stack to people.
- Each engineer connects GitHub on Connections and launches their manifest. See Create a space.
- Review what the spaces did on Audit and on Dashboards > Security. See Read the audit log.
Make it yours
- One environment per team. Give the Platform team its own stack and a team-owned manifest bound to the team’s GitHub credential. Every team member gets the same access, and nobody sees the token. See Share a credential with a team.
- A stricter policy for production work. Attach a policy that forbids self-service additions. Engineers can still use Approve for one space, and only an admin can add an address for good.
- Keep costs in line. Allow only Small to Large on the stack, turn on idle auto-stop, and set an idle time on the manifest so unused spaces stop on their own.
- Roll out a change. Edit the draft, publish v2, and let engineers choose Upgrade to in the manifest editor. Running spaces stay on v1 until they stop, and move to v2 when they resume.