What causes "Cannot access `nodes.service` in dev mode." in anomalyco/sst?

Only access `nodes.service` in deploy mode; branch on the dev flag (or run the code only during `sst deploy`).

anomalyco/sst · error · VisibleError

Cannot access `nodes.service` in dev mode.

Error message

Cannot access `nodes.service` in dev mode.

What it means

In `sst dev` (dev mode) the Service does not run as an ECS service on AWS — it runs locally via DevCommand — so the underlying `nodes.service` (the Amazon ECS Service resource) does not exist. Accessing `nodes.service` in dev mode throws this VisibleError to prevent referencing a resource that was never created.

Source

Thrown at platform/src/components/aws/service.ts:2882

        return this.dev
          ? interpolate`dev.${namespace}`
          : interpolate`${service!.name}.${namespace}`;
      },
    );
  }

  /**
   * The underlying [resources](/docs/components/#nodes) this component creates.
   */
  public get nodes() {
    const self = this;
    return {
      /**
       * The Amazon ECS Service.
       */
      get service() {
        if (self.dev)
          throw new VisibleError("Cannot access `nodes.service` in dev mode.");
        return self._service!;
      },
      /**
       * The Amazon ECS Execution Role.
       */
      executionRole: this.executionRole,
      /**
       * The Amazon ECS Task Role.
       */
      taskRole: this.taskRole,
      /**
       * The Amazon ECS Task Definition.
       */
      get taskDefinition() {
        if (self.dev)
          throw new VisibleError(
            "Cannot access `nodes.taskDefinition` in dev mode.",
          );

View on GitHub (pinned to a0bd20f762)

Solutions

Only access `nodes.service` in deploy mode; branch on the dev flag (or run the code only during `sst deploy`).
Use `nodes.executionRole` or other resources that are available in dev if that's what you actually need.
If you need the ECS service reference in dev, skip it — there is no ECS service during dev by design.

Example fix

// before
export const ecsService = svc.nodes.service; // throws in sst dev
// after
export const ecsService = $dev ? null : svc.nodes.service;

Defensive patterns

Strategy: type-guard

Validate before calling

if (isDev() && needEcsServiceNode) {
  throw new Error("nodes.service is only available in deploy mode");
}

Type guard

function hasEcsServiceNode(svc: { nodes: { service?: unknown } }): boolean {
  return svc.nodes.service != null;
}

Try / catch

let ecsService;
try {
  ecsService = svc.nodes.service;
} catch (e) {
  if (e instanceof VisibleError && e.message.includes("Cannot access `nodes.service` in dev mode")) {
    ecsService = null; // no ECS service exists during sst dev
  } else {
    throw e;
  }
}

Prevention

Gate `nodes.service` access behind a deploy-mode check (e.g. `$dev ? null : svc.nodes.service`).
Use `nodes.executionRole` or other dev-available resources when possible.
Never export ECS service nodes unconditionally from stack files that also run in dev.
Structure IAM/policy code so ECS-only references live in deploy-only code paths.

When it happens

Trigger: Reading `myService.nodes.service` while running `sst dev` on a Service configured for local development. It only succeeds in deploy mode where the ECS service resource exists.

Common situations: Shared IAM/policy code that references the ECS service node being executed during local dev; writing exports or grants that unconditionally read `nodes.service` and then running the dev session; tests that run against dev infrastructure.

Related errors

AI-assisted analysis of anomalyco/sst@a0bd20f762 (2026-08-30). Data as JSON: /api/errors/b31b062fd089e3b4. Report an issue: GitHub.