Multiple Deployments, One Config File

If you're building with AI agents, you probably don't have just one. Say you're building a lead aggregation pipeline. You've got one agent that scrapes company websites, another that pulls leads from LinkedIn, and a third that mines Reddit and community forums. They all share the same data models and scoring logic, they all run on a schedule, and they all live in the same repo. But each one deploys independently, so each one needs its own crewship.toml and its own deploy commands, which adds up fast.

It works, but it's clunky. You end up duplicating build settings, keeping exclude lists in sync, and jumping between directories every time you deploy.

We kept hearing this from teams building multi-agent systems, and honestly ran into it ourselves. So we fixed it.

One file, multiple deployments

You can now define multiple deployments in a single crewship.toml. Instead of one [deployment] section, use named [deployments.<name>] sections:

[build]
exclude = ["tests", "notebooks"]

[deployments.web-scraper]
framework = "crewai"
entrypoint = "leads.web_scraper.crew:WebScraperCrew"
profile = "browser"
python = "3.11"

[deployments.linkedin-miner]
framework = "crewai"
entrypoint = "leads.linkedin.crew:LinkedInCrew"

[deployments.reddit-miner]
framework = "crewai"
entrypoint = "leads.reddit.crew:RedditCrew"

Each named section becomes its own deployment on Crewship, with the name as the project name. The [build] config is shared across all of them, so you only declare your exclude list once.

That's it. No wrapper scripts, no monorepo tooling, no separate directories. Three lead miners, one file.

Deploying and targeting

Every CLI command now takes a --name (or -n) flag to target a specific deployment:

crewship deploy --name web-scraper
crewship deploy --name linkedin-miner
crewship deploy --name reddit-miner

Same for env vars, invocations, and schedules. For a lead pipeline where every source runs on its own schedule, that looks like:

crewship env set --name linkedin-miner LINKEDIN_API_KEY=...
crewship env set --name reddit-miner REDDIT_CLIENT_ID=... REDDIT_CLIENT_SECRET=...

crewship schedule create --name web-scraper "Scrape targets" --cron "0 */6 * * *"
crewship schedule create --name linkedin-miner "LinkedIn sync" --cron "0 8 * * 1-5"
crewship schedule create --name reddit-miner "Reddit sweep" --cron "0 9 * * *"

If you skip --name and there's only one deployment in the file, it gets picked automatically. If there are multiple, the CLI prompts you to choose. In CI where there's no TTY, it'll error and tell you to pass --name explicitly, so you don't accidentally deploy the wrong thing.

Deployment IDs are tracked per deployment

After the first deploy, Crewship saves the deployment_id back into the config for each deployment:

[deployments.web-scraper]
framework = "crewai"
entrypoint = "leads.web_scraper.crew:WebScraperCrew"
deployment_id = "dep_abc123"   # auto-populated after first deploy

[deployments.linkedin-miner]
framework = "crewai"
entrypoint = "leads.linkedin.crew:LinkedInCrew"
deployment_id = "dep_def456"   # auto-populated after first deploy

This means subsequent deploys know exactly which deployment to update without you having to track IDs manually. Commit the file to version control and your whole team stays in sync.

Nothing breaks

If you've got an existing crewship.toml with a single [deployment] section, nothing changes. That format works exactly as before. The new multi-deployment format is opt-in, and crewship init still generates the single-deployment config by default.

The two formats are mutually exclusive. If you accidentally mix [deployment] and [deployments.*] in the same file, the CLI catches it and tells you what to do.

When this matters

The lead aggregator setup is a good example, but it applies anywhere you have agents that share code but deploy separately. A few patterns that fall out of this naturally:

• Monorepo without the mess — your lead miners share scoring logic, data models, and utility code. With multi-deployment, they stay in one repo and one config file instead of being split across separate projects that drift out of sync.
• Independent schedules — each source runs on its own cadence. The web scraper every 6 hours, LinkedIn on weekday mornings, Reddit once a day. Set them up with crewship schedule create --name and they run independently.
• Gradual rollout — deploy one miner at a time, verify it works, then deploy the next. Each deployment has its own version history and rollback.

Getting started

If you're starting from scratch, crewship init sets up a single-deployment config. When you're ready to add more agents, edit the file to use the named format:

# Before
[deployment]
framework = "crewai"
entrypoint = "leads.web_scraper.crew:WebScraperCrew"

# After
[deployments.web-scraper]
framework = "crewai"
entrypoint = "leads.web_scraper.crew:WebScraperCrew"

[deployments.linkedin-miner]
framework = "crewai"
entrypoint = "leads.linkedin.crew:LinkedInCrew"

Deploy them, set their env vars, invoke them. Everything else works the same.

Full details are in the configuration docs. If you run into anything or have feedback, reach out -- we'd like to hear how you're using it.