Snowpark Container Services: New Stage Mount V1 services and jobs no longer accepted (Disabled by default)¶

When the 2026_08 bundle is enabled, Snowpark Container Services rejects new services and jobs that use Stage Mount V1, the deprecated stage volume implementation. Existing V1 services are not affected.

Before the change:

You can create services and jobs that use Stage Mount V1. A Stage Mount V1 volume specifies a raw stage URL as its source, for example source: "@database.schema.stage/path".

After the change:

New Stage Mount V1 services and jobs are no longer accepted. CREATE SERVICE and EXECUTE JOB SERVICE fail with the following error when the specification contains a Stage Mount V1 volume:

Copy code

stage mount v1 not supported, please use v2 instead

Existing V1 services continue to run, and you can still change them with ALTER SERVICE … FROM SPECIFICATION. However, you should plan to migrate them to Stage Mount V2.

Impact on Snowflake ML Jobs¶

Snowflake ML Jobs submitted from snowflake-ml-python versions earlier than 1.35.0 use Stage Mount V1. Because snowflake-ml-python builds the service specification on the client and each job submission creates a new service, these job submissions fail when Stage Mount V1 is disabled. Snowflake can’t migrate these jobs on the server side, so you must upgrade the client.

snowflake-ml-python versions 1.35.0 and later use Stage Mount V2 and aren’t affected, unless you’ve set the override parameter that forces Stage Mount V1.

To prepare for this change, do the following in every environment that submits ML Jobs:

• Upgrade snowflake-ml-python to version 1.35.0 or later. There’s no known behavior change for your jobs. Earlier versions also use outdated container runtime images, so upgrading moves your jobs onto current images.
• If you’ve set the override parameter that forces Stage Mount V1, remove it.

For ML Jobs, you don’t need to change volume definitions as described in the following section.

Migrating to Stage Mount V2¶

The migration requires changing the volume definition from a raw stage URL to source: stage with the stage specified under stageConfig.name, while keeping the same volume name and container mount path:

# Stage Mount V1
spec:
  volumes:
    - name: model-data
      source: "@database.schema.stage/path"

# Stage Mount V2
spec:
  volumes:
    - name: model-data
      source: stage
      stageConfig:
        name: "@database.schema.stage/path"

Because V1 and V2 use different mount implementations, the service must be restarted as part of the migration. Stage Mount V2 does not support random writes or file appends, so workloads that depend on in-place file updates or file-based locking should evaluate block storage instead. For details, see Using Snowflake stage volumes with services.

Ref: 2449