anomalyco/sst · error · VisibleError

Cannot access "nodes.cloudmapService" for the "${self._name}

Error message

Cannot access "nodes.cloudmapService" for the "${self._name}" Service. Cloud Map is not configured for the cluster.

What it means

SST's Service component (ECS/Fargate) exposes `nodes.cloudmapService` only when the underlying AWS Cloud Map service was created for the cluster. When the Service runs with cloudMap not configured (or in a mode where no Cloud Map service exists), the getter returns undefined and SST throws this VisibleError instead of handing back an undefined Pulumi resource.

Source

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

      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: {
        url: this.dev ? this.devUrl : this._url,
        service: output(this.cloudmapNamespace).apply((namespace) =>
          namespace ? this.service : undefined,
        ),
      },
    };

View on GitHub (pinned to a0bd20f762)

Solutions

Add or fix the `cloudMap` prop on the Service component so a Cloud Map service is created
If you only need the URL/link, use `service.url` or getSSTLink properties instead of nodes.cloudmapService
Verify the cluster/namespace referenced by cloudMap exists so the service can be created

Example fix

// before
new sst.aws.Service("MyService", { cluster });
const cm = svc.nodes.cloudmapService; // throws
// after
new sst.aws.Service("MyService", { cluster, cloudMap: true });
const cm = svc.nodes.cloudmapService;

Defensive patterns

Strategy: validation

Validate before calling

if (!svcArgs.cloudMap) {
  throw new Error("Set cloudMap: true on the Service before accessing nodes.cloudmapService");
}

Type guard

function hasCloudmapService(svc: sst.aws.Service & { nodes: { cloudmapService?: unknown } }): boolean {
  return svc != null && svc.nodes?.cloudmapService != null;
}

Try / catch

try {
  const cm = svc.nodes.cloudmapService;
} catch (e) {
  // fall back to svc.url or configure cloudMap
}

Prevention

Always pass cloudMap: true when you plan to reference nodes.cloudmapService
Prefer the Service's url/link properties over raw nodes unless you need the resource
Never access nodes.* getters in `sst dev` for Service components (dev mode throws its own error)

When it happens

Trigger: Accessing `service.nodes.cloudmapService` on a Service component created without the `cloudMap` prop (or with a service/namespace setup that yields no Cloud Map service).

Common situations: Referencing nodes.cloudmapService in another component (e.g. to register a custom domain or link the service) while the Service was declared without cloudMap discovery settings; copying example code that assumed cloudMap was enabled by default.

Related errors

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