Background
The CLI currently selects a plan in two ways:
--plan Essential — you pass the tier name and plan.ts checks it against the keys returned by api.listSubscriptions() (Record<planName, slotCount>).
- Interactively — if you have multiple tiers available, the CLI prompts you to pick one.
This works fine when a user has one subscription per tier. But a user with multiple subscriptions of the same tier (e.g. two "Essential" plans) has no way to target a specific one. The backend already tracks subscription instances: api.listSubscriptionsDeploys() returns SubscriptionDeploy[] where each entry has:
interface SubscriptionDeploy {
id: string;
plan: Plans;
date: number;
deploy: string;
}
// id === the SHA-like instance ID e.g. "a3f9c2d1..."
// plan === tier: "Essential" | "Standard" | "Premium"
// deploy === deployment suffix using this subscription
The id field is the subscription instance ID — that's what --plan-id should target.
What's needed
A --planId flag so a CI pipeline or power user can pin a deploy to an exact subscription instance:
metacall-deploy --planId a3f9c2d1... --workdir ./my-project
What has to change
CLI side (src/):
-
Add planId?: string to CLIArgs in src/cli/args.ts.
- Note: the TODO listed
-d as the alias but -d is already taken by --dev. A new alias (e.g. --planId with no short alias, or -S for subscription) needs to be agreed on.
-
In src/plan.ts, after fetching availPlans, check for args['planId'] and validate it exists in listSubscriptionsDeploys() before using it.
-
In src/deploy.ts, api.deploy() today receives a Plans tier string:
api.deploy(name, env, plan: Plans, resourceType, release, version)
It would need a new optional planId parameter threaded through to the POST /api/deploy/create body.
-
src/force.ts already reads repoSubscriptionDetails[0].plan to recover the tier on re-deploy. With this change it should also propagate repoSubscriptionDetails[0].id when available.
Backend side (/api/deploy/create):
The deploy endpoint currently accepts plan (tier name). It needs to optionally accept planId (subscription instance ID) and use it to pick the right subscription slot when provided.
This is the blocking part — the CLI work can be prepared, but the feature isn't useful until the backend supports it.
Why it matters
- Users with multiple active subscriptions of the same tier can't automate targeted deploys today.
- CI pipelines can't hard-pin a specific subscription instance across runs.
Alias conflict to resolve
The original TODO says (-d, --plan-id) but -d is already owned by --dev. This needs to be decided before implementation starts.
Next Steps
Willing to Implement
I'm ready to contribute! I can handle:
Blocking: Awaiting maintainer feedback on the alias conflict before starting.
Background
The CLI currently selects a plan in two ways:
--plan Essential— you pass the tier name andplan.tschecks it against the keys returned byapi.listSubscriptions()(Record<planName, slotCount>).This works fine when a user has one subscription per tier. But a user with multiple subscriptions of the same tier (e.g. two "Essential" plans) has no way to target a specific one. The backend already tracks subscription instances:
api.listSubscriptionsDeploys()returnsSubscriptionDeploy[]where each entry has:The
idfield is the subscription instance ID — that's what--plan-idshould target.What's needed
A
--planIdflag so a CI pipeline or power user can pin a deploy to an exact subscription instance:What has to change
CLI side (
src/):Add
planId?: stringtoCLIArgsinsrc/cli/args.ts.-das the alias but-dis already taken by--dev. A new alias (e.g.--planIdwith no short alias, or-Sfor subscription) needs to be agreed on.In
src/plan.ts, after fetchingavailPlans, check forargs['planId']and validate it exists inlistSubscriptionsDeploys()before using it.In
src/deploy.ts,api.deploy()today receives aPlanstier string:It would need a new optional
planIdparameter threaded through to thePOST /api/deploy/createbody.src/force.tsalready readsrepoSubscriptionDetails[0].planto recover the tier on re-deploy. With this change it should also propagaterepoSubscriptionDetails[0].idwhen available.Backend side (
/api/deploy/create):The
deployendpoint currently acceptsplan(tier name). It needs to optionally acceptplanId(subscription instance ID) and use it to pick the right subscription slot when provided.This is the blocking part — the CLI work can be prepared, but the feature isn't useful until the backend supports it.
Why it matters
Alias conflict to resolve
The original TODO says
(-d, --plan-id)but-dis already owned by--dev. This needs to be decided before implementation starts.Next Steps
--planIdvs-Svs alternative)planIdparameter in/api/deploy/createsrc/force.tsto propagate subscription instance ID on re-deployWilling to Implement
I'm ready to contribute! I can handle:
src/cli/args.ts,src/plan.ts,src/deploy.ts,src/force.ts)Blocking: Awaiting maintainer feedback on the alias conflict before starting.