deploy
AI Stack Composer
Point It At More Than One Repo. The AI Proposes A Stack, And ZipLoom Creates One Project Per Service And Wires Their URLs Together.
What you get
Many Repos, One Plan
Point the composer at up to 10 repositories. It reads them and proposes the services in the stack — front end, back end and workers — with each one's framework, port and the environment variables it expects.
One Project Per Service
Create Projects makes one ZipLoom project for each service, using the repository, branch and host you confirm. It does not merge the repositories into a single deployment, and a service you already have is reused instead of copied.
URLs Wired At Deploy Time
For each service you choose which variable should hold another service's live URL — a front end's API address, for example — and ZipLoom fills it in when that service deploys. A value you have already set yourself is never overwritten. The common front-end-plus-API case is prefilled for you.
Checked Before Each Deploy
Every service deploys through ZipLoom's normal pre-deploy checks — dependency audit, code scan and license check — and a blocking finding stops that service's deploy.
How The Composer Works
- 1
You point ZipLoom at the repositories you want combined.
- 2
The AI proposes the services and their configuration. You edit the plan, then create one project per service with their URLs wired.
- 3
You deploy the projects in order. Each deploy runs ZipLoom's security checks before anything is built.
What this check inspects
Each repository's manifests, env examples, Dockerfiles and configs, when GitHub is connected — otherwise the plan says it was inferred from the repository name only.
Which service looks like the front end, the API or a worker, with its framework and port — proposed by the AI from those files, for you to check.
The environment variables the services expect, from env example files and source code.
Which of those variables look like another service's address (NEXT_PUBLIC_API_URL, for example), so the wiring can be prefilled.
What it means when this fails
AI tools tend to produce a front end and an API as separate projects that were never introduced to each other. The composer proposes how they connect and, once you confirm it, sets the address variables for you at deploy time. Keys, database connection strings and other secrets are still yours to add to each project; the composer lists the variables it detected.
Questions
- What if it guesses wrong?
- The plan is shown before anything is created or deployed. You can change each service's name, repository, branch and host, add or remove wiring, and leave a service out. Nothing is created until you click Create Projects, and nothing is deployed until you click Deploy.
- Does it work with more than two repos?
- Yes, up to 10 repositories in one plan.
- Do I need a monorepo?
- No. Separate repositories are the expected shape: each service becomes its own project. ZipLoom keeps one project per repository, branch and host, so it can't yet split one repository into several projects.
- Does it deploy everything at once?
- No. It creates the projects and shows the order to deploy them in; you start each deploy yourself. If a service's address isn't available yet because the service it depends on hasn't been deployed, the deploy log names the variable that was left unset and the deploy carries on.
- Does it share keys or secrets between services?
- No. Only service addresses — public URLs — are wired. API keys, database connection strings and other secrets are set on each project and are never copied from one project to another.
Related features