Snowpark Container Services (SPCS) deployment, debugging, and configuration. Covers service specs, OAuth token auth, env var rules, image management, connection pooling, and troubleshooting. Use when deploying SPCS services, debugging container issues, or writing service specs.
This skill covers deploying and operating containerized applications on Snowflake's Snowpark Container Services (SPCS). It provides universal patterns for service specs, authentication, connection management, debugging, and CI/CD — applicable to any SPCS-hosted application.
Use this skill when:
Snowflake automatically injects the following environment variables into every SPCS container. NEVER set these manually in the service spec — doing so overrides the correct internal values and breaks connectivity.
| Variable | Auto-Provided Value (example) | What Happens If You Override |
|---|---|---|
SNOWFLAKE_ACCOUNT | <LOCATOR> (e.g. AB12345) | Connection may fail if format differs |
SNOWFLAKE_HOST | <locator>.<region>.snowflakecomputing.com | Connection WILL fail — the external hostname is unreachable from inside SPCS |
SNOWFLAKE_DATABASE | Service's database | Usually safe to override, but unnecessary |
SNOWFLAKE_SCHEMA | Service's schema | Usually safe to override |
The auto-provided SNOWFLAKE_HOST uses an internal hostname that includes the region:
<locator>.<region>.snowflakecomputing.com
If you hardcode SNOWFLAKE_HOST=<LOCATOR>.snowflakecomputing.com in the service spec (without the region), the container will try to reach the external Snowflake endpoint, which is NOT routable from inside SPCS (unless you configure an external access integration + network rule). The connection will fail with:
snowflake.connector.errors.OperationalError: 250001: Could not connect to Snowflake backend after 2 attempt(s).
# CORRECT - only set what Snowflake does NOT auto-provide