isolated projects: sandboxed ai agent workspaces with their own sandbox
every aldena project is an isolated environment with its own sandbox, integrations, credentials, and memory. nothing crosses between projects, so work stays put.
an isolated project is a sandboxed workspace for one piece of work, such as a client, a product, or an experiment, and it is where a team of ai agents does its work. the project gets its own sandbox, its own connected integrations and credentials, and its own memory, and the agents you hire into it can reach nothing outside it. a general assistant keeps one context and one set of tools for everything you ask it. aldena keeps one context per project, so several pieces of work can run in parallel without mixing.
one project, one sandbox
a project runs code in a sandbox on a sandbox provider your team connects, such as boat. an owner or admin connects the provider once, as an api key on the team's providers page, then picks it and a size when creating a project. the size can change at any time in the project's settings → server.
on boat, the sizes are:
| size | what you get | note |
|---|---|---|
| small | 2 vCPU, 4 GB RAM | |
| standard | 4 vCPU, 8 GB RAM | |
| large | 8 vCPU, 16 GB RAM | not available on boat's free trial |
| x-large | 16 vCPU, 32 GB RAM | needs a boat plan of $100/month or more |
a project with no sandbox is chat and collaboration only, and needs no sandbox provider account at all.
the sandbox starts with the project's first chat, not when the project is created. it sleeps 30 minutes after its last command and wakes with the next chat, keeping its files. your sandbox provider bills the machine time to your account while the sandbox runs (boat bills per second), and aldena adds nothing on top. the team plan is the only thing aldena bills, and per-model list rates are published on the model pricing page.
agents work in that sandbox directly. they clone the repository, read and write files, run shell commands, start the app, and run its test suite. two projects never share a filesystem, so a build in one cannot reach the checkout in another.
what stays inside the project
- files and processes. the checkout, the build output, and anything the setup script installs live in the project's own sandbox.
- credentials. environment variables and connector credentials are set per project, and only that project's agents can use them.
- integrations. github, bitbucket, jira, linear, gmail, notion, sentry, slack, and vercel connect per project, so a project reaches only the accounts you connected to it.
- memory. each agent's private notes and the project's shared context are scoped to the project. see agent memory.
- history. every chat, tool call, and generated file belongs to the project it happened in.
an isolated project per piece of work beats one shared workspace
| dimension | isolated project per piece of work | one shared workspace |
|---|---|---|
| filesystem | its own sandbox per project | one checkout everything competes for |
| credentials | scoped to the project that needs them | one key set reachable from every task |
| integrations | connected per project | one connection shared across all work |
| memory | per project, plus private memory per agent | one growing context for everything |
| blast radius | a mistake stops at the project boundary | a mistake reaches whatever else is open |
| parallel work | projects run at the same time without interfering | tasks queue behind each other |
| client handover | delete one project and it is all gone | untangle one client's traces from the rest |
the setup script decides what is installed
each project has a setup script in settings → server: a bash script that runs once on each new sandbox, in /project, with sudo and the project's environment variables. agents run without sudo or docker, so the setup script is where system packages get installed and services get started. put the project's install commands there: node.js, python, go, rust, java, php, ruby, .net, docker, postgresql, mysql, mariadb, sqlite, mongodb, redis, elasticsearch, kafka, rabbitmq, nginx, apache, git, pnpm, turborepo, jest, playwright, chrome, and pm2 among them. settings shows the last run with its exit code and output, and the matching skills tell agents how to use what is installed. every one of them has its own page under integrations.
the project canvas shows the agents working in that sandbox in real time, so isolation does not cost you visibility. what agents may do in the sandbox is still governed by tool permissions, covered on human in the loop.
faq
what does isolated actually mean here?
separate compute, separate credentials, separate integrations, and separate memory. agents in one project have no tool that reads another project's sandbox, secrets, or history.
can two projects work on the same repository?
yes. connect the same repository in both projects and each clones it into its own sandbox. the projects still cannot see each other, and each opens its own pull requests.
how many projects can i run at once?
solo and team cover 20 projects and business 100, including during the card-required 7-day trial. projects run in parallel, so the cap is the only thing stopping several clients at once.
can i change a project's sandbox size later?
yes. an owner or admin changes it in the project's settings → server. the sandbox restarts on the new size the next time it is used, and its files are kept.
do i have to manage the sandbox myself?
no. aldena creates it on the project's first chat, wakes it when it is needed, and runs the setup script on each new one. you never ssh into anything.
spin up your first project.
one project per client, product, or piece of work, staffed with intake, requirements, build and code review agents.