anomalyco/sst · error · VisibleError
Cannot access `nodes.autoScalingTarget` in dev mode.
Error message
Cannot access `nodes.autoScalingTarget` in dev mode.
What it means
`nodes.autoScalingTarget` exposes the Application Auto Scaling target, which only exists when autoscaling is configured on the Service. In dev mode the resource is not created at all, so the getter throws this VisibleError immediately instead of returning an undefined node.
Source
Thrown at platform/src/components/aws/service.ts:2922
* The Amazon Elastic Load Balancer.
*/
get loadBalancer() {
if (self.dev)
throw new VisibleError(
"Cannot access `nodes.loadBalancer` in dev mode.",
);
if (!self.loadBalancer)
throw new VisibleError(
"Cannot access `nodes.loadBalancer` when no public ports are exposed.",
);
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.`,
);View on GitHub (pinned to a0bd20f762)
Solutions
- Wrap the access in `$dev` from `sst/dev` and skip autoscaling-related wiring in dev mode.
- Run `sst deploy` for workflows that need the actual Application Auto Scaling target resource.
- If you also need autoscaling on deploy, additionally verify `scaling` args are set or the non-dev getter will fail on the non-null assertion.
Example fix
// before
const target = service.nodes.autoScalingTarget;
// after
import { $dev } from "sst/dev";
const target = $dev ? undefined : service.nodes.autoScalingTarget; Defensive patterns
Strategy: validation
Validate before calling
import { $dev } from "sst/dev";
if (!$dev) {
const target = service.nodes.autoScalingTarget; // requires scaling configured on deploy
} Type guard
import { $dev } from "sst/dev";
const hasAutoScalingTarget = (): boolean => !$dev; Try / catch
try {
const target = service.nodes.autoScalingTarget;
} catch (e) {
if (String(e).includes("in dev mode")) {
// skip autoscaling wiring in dev
} else throw e;
} Prevention
- Gate autoscaling node access behind `$dev`.
- Only reference the scaling target when the Service defines `scaling` args.
- Validate infra code under `sst dev` regularly to catch environment-dependent access early.
When it happens
Trigger: Reading `service.nodes.autoScalingTarget` while the app runs under `sst dev` (dev mode active), regardless of autoscaling configuration.
Common situations: Custom scaling policies or CloudWatch alarms that reference the scaling target; the code works on `sst deploy` but the developer hits the error when iterating locally with `sst dev`.
Related errors
- Cannot access `nodes.taskDefinition` in dev mode.
- Cannot access `nodes.loadBalancer` in dev mode.
- Cannot access `nodes.cluster` in dev mode.
- Cannot access `nodes.service` in dev mode.
- Cannot access `nodes.taskDefinition` in dev mode.
AI-assisted analysis of anomalyco/sst@a0bd20f762 (2026-08-30).
Data as JSON: /api/errors/60f9786eb6b96ef1.
Report an issue: GitHub.