anomalyco/sst · error · VisibleError

You are using the "Vpc.v1" component. Please migrate to the

Error message

You are using the "Vpc.v1" component. Please migrate to the latest "Vpc" component.

What it means

The legacy Vpc.v1 component is not compatible with newer components like MySql, which require the redesigned Vpc component. Passing a Vpc.v1 instance to the vpc argument throws this VisibleError prompting migration.

Source

Thrown at platform/src/components/aws/mysql.ts:581

        const size = toGBs(v);
        if (size < 20) {
          throw new VisibleError(
            `Storage must be at least 20 GB for the ${name} MySQL database.`,
          );
        }
        if (size > 65536) {
          throw new VisibleError(
            `Storage cannot be greater than 65536 GB (64 TB) for the ${name} MySQL database.`,
          );
        }
        return size;
      });
    }

    function normalizeVpc() {
      // "vpc" is a Vpc.v1 component
      if (args.vpc instanceof VpcV1) {
        throw new VisibleError(
          `You are using the "Vpc.v1" component. Please migrate to the latest "Vpc" component.`,
        );
      }

      // "vpc" is a Vpc component
      if (args.vpc instanceof Vpc) {
        return {
          subnets: args.vpc.privateSubnets,
        };
      }

      // "vpc" is object
      return output(args.vpc);
    }

    function registerDev() {
      if (!args.dev) return undefined;

View on GitHub (pinned to a0bd20f762)

Solutions

Replace sst.aws.Vpc.v1 instantiation with the new sst.aws.Vpc component and pass that instance to MySql
Migrate VPC arguments (nat gateways, subnets, etc.) to the new Vpc component's API
Re-deploy so the new Vpc is created, then attach it to the MySQL component

Example fix

// before
const vpc = new sst.aws.Vpc.v1("MyVpc", { nat: "managed" });
new sst.aws.MySql("MyDb", { vpc });
// after
const vpc = new sst.aws.Vpc("MyVpc", { nat: "managed" });
new sst.aws.MySql("MyDb", { vpc });

Defensive patterns

Strategy: type-guard

Validate before calling

import { Vpc, Vpc as VpcNew } from "sst/aws";
if (args.vpc instanceof VpcV1) throw new Error("Migrate Vpc.v1 to new Vpc before using with MySql");

Type guard

function isLegacyVpc(v: unknown): v is VpcV1 {
  return v instanceof VpcV1;
}

Prevention

Migrate all Vpc.v1 usages to the new Vpc component first in any upgrade
Search for `Vpc.v1` during SST upgrades and remove all occurrences
Type the vpc argument as the new Vpc class so legacy instances fail typecheck
Review SST migration guides before changing shared networking components

When it happens

Trigger: new sst.aws.MySql("MyDb", { vpc: someVpcV1Instance }) where someVpcV1Instance was created with sst.aws.Vpc.v1.

Common situations: Projects mid-migration from the old Vpc component that still instantiate Vpc.v1 in some stacks; examples copied from older SST versions.

Related errors

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