feat(cli): add --sides flag to cedar deploy baremetal

[lisa-assistant]

Background

In packages/cli/src/commands/deploy/baremetal.js at line 96:

// TODO: Allow option to pass --sides and only deploy select sides instead of all, always

The cedar deploy baremetal command always deploys all sides defined in deploy.toml (defaulting to ['api', 'web']). There is no way to deploy only the api or only the web side from the CLI.

What needs to be done

Add a --sides CLI option to cedar deploy baremetal that lets users specify which sides to deploy in a given run.

Changes required

packages/cli/src/commands/deploy/baremetal.js — add the yargs option:

yargs.option('sides', {
  describe: 'Which sides to deploy (defaults to all sides in deploy.toml)',
  type: 'array',
  choices: ['api', 'web'],
})

packages/cli/src/commands/deploy/baremetal/baremetalHandler.js — filter the sides:

The handler reads sides from serverConfig.sides (line 23, defaulting to ['api', 'web']). When yargs.sides is provided, filter:

const sidesToDeploy = yargs.sides?.length
  ? serverConfig.sides.filter((s) => yargs.sides.includes(s))
  : serverConfig.sides

Then use sidesToDeploy in the deploy loop at line 398 (for (const side of serverConfig.sides)).

Use case

Useful for deployments where the API and web side are deployed at different cadences, or for partial rollbacks where only one side needs redeploying.

File

packages/cli/src/commands/deploy/baremetal.js, line 96

[lisa-assistant]

Self-fix confidence: 8/10
The yargs option and filter logic are straightforward. The main thing to validate is that filtering the sides array integrates cleanly with the rest of the baremetalHandler deploy loop without breaking the config-driven defaults.

[lisa-assistant]

Implementation Plan

Context from the code

packages/cli/src/commands/deploy/baremetal.js defines all the yargs options. handler() delegates to baremetalHandler(yargs).

In baremetalHandler.js:

• Line 23: DEFAULT_SERVER_CONFIG has sides: ['api', 'web']
• Line 87: serverConfigWithDefaults(serverConfig, yargs) merges server-level config from deploy.toml with CLI args (currently only branch is overridable from the CLI)
• Line 398: for (const side of serverConfig.sides) is the loop that builds tasks for each side

Change 1 — packages/cli/src/commands/deploy/baremetal.js

Add the yargs option in the builder function, after the existing options and before the yargs.epilogue() call at line 95:

yargs.option('sides', {
  describe: 'Sides to deploy (defaults to all sides in deploy.toml)',
  type: 'array',
  default: undefined,
})

Using default: undefined (not []) so that omitting the flag and passing no values are distinguishable — yargs.sides === undefined means "use whatever deploy.toml says"; yargs.sides === [] would be an error case.

Change 2 — packages/cli/src/commands/deploy/baremetal/baremetalHandler.js

Update serverConfigWithDefaults to apply the CLI filter:

export const serverConfigWithDefaults = (serverConfig, yargs) => {
  const config = {
    ...DEFAULT_SERVER_CONFIG,
    ...serverConfig,
    branch: yargs.branch || serverConfig.branch || DEFAULT_SERVER_CONFIG.branch,
  }

  // If --sides is given, filter to only the requested sides
  if (yargs.sides?.length) {
    const validSides = config.sides
    const invalid = yargs.sides.filter((s) => !validSides.includes(s))
    if (invalid.length) {
      throw new Error(
        `Unknown side(s): ${invalid.join(', ')}. Valid sides for this server: ${validSides.join(', ')}`
      )
    }
    config.sides = yargs.sides
  }

  return config
}

The validation check ensures a typo like --sides apu gives a clear error rather than silently deploying nothing.

Files to change

File	Change
packages/cli/src/commands/deploy/baremetal.js	Add --sides yargs option
packages/cli/src/commands/deploy/baremetal/baremetalHandler.js	Filter config.sides in serverConfigWithDefaults

Edge cases

• Multi-server deploy.toml: each server entry can have its own sides. The filter is applied per-server inside serverConfigWithDefaults, which is called once per server block. If a server doesn't have a web side but --sides web is passed, the validation will throw. This is the correct behavior.
• --sides with a single value: yargs type: 'array' means --sides api becomes ['api'] — no special handling needed.
• --build false: the --sides flag only filters the build loop at line 398. Other steps (migrate, install, restart) are not side-specific, so they always run unless their own flag is set to false. This is the right scoping.
• Telemetry: add sides: yargs.sides to the recordTelemetryAttributes call in handler() for observability.