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

Gate the access with `$dev` from `sst/dev` and provide a dev-mode alternative (e.g. the `dev.url`/`devPassword` style endpoints the component exposes).

anomalyco/sst · error · VisibleError

Cannot access `nodes.cloudmapService` in dev mode.

Error message

Cannot access `nodes.cloudmapService` in dev mode.

What it means

`nodes.cloudmapService` exposes the AWS Cloud Map service used for service discovery. In dev mode no Cloud Map service resource is created, so the getter throws this VisibleError before even evaluating whether Cloud Map is configured on the cluster.

Source

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

          );
        return self.loadBalancer;
      },
      /**
       * The Amazon Application Auto Scaling target.
       */
      get autoScalingTarget() {
        if (self.dev)
          throw new VisibleError(
            "Cannot access `nodes.autoScalingTarget` in dev mode.",
          );
        return self.autoScalingTarget!;
      },
      /**
       * The Amazon Cloud Map service.
       */
      get cloudmapService() {
        if (self.dev)
          throw new VisibleError(
            "Cannot access `nodes.cloudmapService` in dev mode.",
          );

        return output(self.cloudmapService).apply((service) => {
          if (!service)
            throw new VisibleError(
              `Cannot access "nodes.cloudmapService" for the "${self._name}" Service. Cloud Map is not configured for the cluster.`,
            );
          return service;
        });
      },
    };
  }

  /** @internal */
  public getSSTLink() {
    return {
      properties: {

View on GitHub (pinned to a0bd20f762)

Solutions

Gate the access with `$dev` from `sst/dev` and provide a dev-mode alternative (e.g. the `dev.url`/`devPassword` style endpoints the component exposes).
Run `sst deploy` if the Cloud Map resource is genuinely needed.
Also ensure Cloud Map is configured for the cluster; in deploy mode the same getter throws a separate 'Cloud Map is not configured' error.

Example fix

// before
const cm = service.nodes.cloudmapService;

// after
import { $dev } from "sst/dev";
const cm = $dev ? undefined : service.nodes.cloudmapService;

Defensive patterns

Strategy: validation

Validate before calling

import { $dev } from "sst/dev";
if (!$dev) {
  const cm = service.nodes.cloudmapService; // also requires Cloud Map configured for the cluster
}

Type guard

import { $dev } from "sst/dev";
const hasCloudmapService = (): boolean => !$dev;

Try / catch

try {
  const cm = service.nodes.cloudmapService;
} catch (e) {
  if (String(e).includes("cloudmapService")) {
    // dev mode or Cloud Map not configured; use alternative discovery
  } else throw e;
}

Prevention

Use `$dev` gating for all service-discovery node access.
Ensure the cluster's Cloud Map settings are configured when relying on discovery in deploy mode.
Prefer the Service's built-in dev URL/endpoints instead of Cloud Map during local development.

When it happens

Trigger: Reading `service.nodes.cloudmapService` while `sst dev` is running on a Service component.

Common situations: Custom service-discovery wiring or DNS lookups referencing the Cloud Map service; code written against a deployed environment then run under `sst dev` for local development.

Related errors

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