Duration: 3

Remote Development in the Snowflake Extension for VS Code provides you with a Snowflake-backed development environment you connect to over Remote-SSH, straight from VS Code or Cursor. There are no SSH keys to manage, no VMs to provision, and no local dependencies to maintain. The environment is a Snowflake Notebook service running on Snowpark Container Services, preloaded with Python, Jupyter, XGBoost, scikit-learn, and the Snowflake libraries, reachable from your editor as if it were localhost.

In this Quickstart, we'll build an end-to-end ML workflow against Snowflake compute, entirely from a local editor. The scenario is the following: you're an ML engineer on the Tasty Bytes team. Tasty Bytes runs food trucks in cities across the globe, and you've been asked to forecast daily sales per truck location. Weather clearly moves food-truck sales – so we'll enrich internal orders with a Marketplace weather share, feature-engineer with help from CoCo, train an XGBoost regressor, and log it to the Snowflake Model Registry, all from VS Code.

Let's get started!

By the end of this guide, you'll have:

Duration: 6

Let's set up everything you'll need on the Snowflake side: a warehouse for the bulk load, the Tasty Bytes database and schemas, an external stage against the public S3 bucket, all the raw tables, a compute pool for the notebook service, an external access integration for outbound GitHub and PyPI, and a Snowflake Workspace to mount into the remote environment.

We'll do it all with one SQL script, run from your terminal via the Snowflake CLI.

Clone the companion repo locally and run setup.sql with the Snowflake CLI:

This executes the whole script against your default snow connection.

Here's what the script does:

You should see a final note row that reads: Setup complete..

Weather is one of the strongest predictors of food-truck sales, so setup.sql already acquired the free Pelmorex Weather Source: Frostbyte share from the Snowflake Marketplace and installed it as the frostbyte_weathersource database. Confirm it's ready with one command:

You should see weather observations for a US city across the first week of January 2024. That's the data we'll join to daily orders in step 6.

Great job – the Snowflake side is ready. Now let's get your editor set up.

Duration: 3

Now we'll install the Snowflake Extension for VS Code (or Cursor) plus the companion Remote - SSH extension, and sign in to your Snowflake account.

1. Open VS Code.
2. In the Extensions view, search for Snowflake and install the extension published by Snowflake Inc. – make sure the version is 1.39.0 or later.
3. In the Extensions view again, search for ms-vscode-remote.remote-ssh. The top results, called Remote - SSH, is the extension to install. Install it.
4. Open the Snowflake extension from the Activity Bar. Sign in to your Snowflake account.

Cursor is built on the same VS Code extension model. Follow the same instructions above for installing the Remote - SSH extension in Cursor.

Duration: 5

We're ready to spin up the remote environment. From the Snowflake extension in your local editor, we'll create a notebook service running on the compute pool we provisioned earlier, and enable persistent storage so cloned Git repos and installed packages survive suspend/resume.

1. In the Snowflake extension sidebar, expand the Remote Environments panel.
2. Click the + sign - hovering over it should read: Snowflake: Create Remote Development Environment.
3. Fill in the form:
   • Service name: tb_forecast_env (or any Snowflake identifier; avoid collisions with existing SSH aliases in your ~/.ssh/config).
   • Workspaces: select tb_forecast_ws.
   • External access integrations: select tb_remote_dev_eai.
   • Secrets: leave this empty. (Only needed for the optional Snowflake-secret auth path in step 8, which recreates the service with a secret attached.)
   • Compute pool: select tb_remote_dev_pool.
   • Expand the Service settings section:
     • Compute type: CPU
     • Runtime version: accept the default (includes XGBoost, scikit-learn, and the Snowflake ML libraries this guide uses).
     • Enable persistent storage: check this box.
4. Click Create.

The service enters PENDING status while Snowflake provisions the container. This takes a few minutes. The panel refreshes every 30 seconds; you can also refresh manually. When the status flips to RUNNING, you're ready to connect.

Duration: 8

Let's connect over SSH.

1. In the Remote Environments panel, find your tb_forecast_env service.
2. Click Connect to Remove Service: SSH.
3. When prompted, select the tb_forecast_ws workspace to mount into the remote environment. Press Enter.
4. A new editor window opens, connected over SSH to the remote container at /root.

Behind the scenes, the extension started a local proxy on 127.0.0.1 that forwards SSH traffic to Snowflake over a secure WebSocket, wrote a Host <service-name> entry to your ~/.ssh/config, installed the required extensions on the remote host, and opened the folder. You didn't have to do any of this manually.

Let's pull the notebook and helper Python modules we'll be using. In the remote window, open a terminal (from the Terminal menu, choose New Terminal) and clone the repo into /mnt/pd0:

Add the folder to your workspace: from the File menu, choose Add Folder to Workspace... and pick /mnt/pd0/sfguide-getting-started-with-remote-development-vscode-extension. You should see README.md, setup.sql, cleanup.sql, forecast.ipynb, and train.py in the Explorer.

Open forecast.ipynb. In the search bar, type Snowflake: Start Notebook Kernel, then select Snowflake Kernel (Python + SQL) from the kernel picker above the notebook.

This is the same kernel that powers Snowflake Notebooks in Snowsight Workspaces. Python and SQL cells run side by side without switching kernels – Python cells run in the container's Python interpreter, and SQL cells run against your Snowflake account.

Run the first SQL cell to confirm the raw tables loaded:

You should see order_detail at the top with the largest row count – hundreds of millions of line items. Together with order_header this is close to a billion rows. You're querying that volume from your local editor, and the query runs on Snowflake compute.

The remote environment isn't limited to notebooks – you can open and run plain Python files against the same remote interpreter. We'll do this in a later step.

Great job. You're now running Snowflake-backed compute from your local editor. Let's put it to work.

Duration: 8

We have 1B rows of raw orders on one side and a weather share on the other. Let's turn them into a modeling-ready feature table.

Run the next cell in the notebook:

Here's what the code does:

Now let's bring in weather. The weather view is keyed at postal-code + date grain, so joining directly on city fans every city out to all of its postal codes (Denver alone has ~74) and explodes the row count. We first pre-aggregate weather to one row per city per date, then join. We also programmatically bump the warehouse to MEDIUM for this step and size it back down right after. Run the next cell (note that it may take about 3 minutes to complete):

Here's what the code does:

Now the fun part. We need calendar, lag, and rolling features on the joined data – the standard patterns for time-series forecasting. We'll let CoCo generate them.

Open the CoCo panel in the remote window from the Activity Bar and try prompts like:

CoCo runs inside the remote SSH session with full access to Snowflake compute and data. By default it shows the generated code in its panel for you to read or copy – it won't change the notebook on its own. If you attach the notebook as context with @, CoCo will instead try to apply its code as edits to the file.

Either way, you don't need to accept any edits: the two cells below are already in the notebook – one defines the transforms, one applies them. Run them as-is to continue, and use CoCo alongside to see how you'd generate them yourself.

The first cell defines three small pandas transforms:

The second cell loads the joined table and chains the transforms via .pipe():

Here's what the code does:

Push the DataFrame back to Snowflake so train.py can consume it:

Now the feature table lives in Snowflake, ready for training.

Duration: 6

This is the step where we ship a model beyond a notebook. We'll train an XGBoost regressor on the feature table, evaluate it on the last week of data, chart actual vs predicted, and log the model to the Snowflake Model Registry – where it becomes discoverable by other teammates and downstream jobs.

train.py in the repo is a plain Python script – no notebook required. Let's run it against the remote environment. In the notebook, execute this cell (use the full path so it runs regardless of the notebook's working directory):

You can also run it directly in the remote terminal (python /mnt/pd0/sfguide-getting-started-with-remote-development-vscode-extension/train.py --source-table ...). Either way it executes on the Snowflake-hosted container. Because a script run this way is a separate process from the notebook kernel, train.py builds its own Snowflake session from the container's credentials (falling back from the kernel's active session), so no extra auth setup is needed.

Here's what train.py does:

You should see output ending in something like (your exact metrics will vary):

Your model is now live in the Model Registry. You can list it from any session:

Great job – you shipped a model. From here, other teammates can retrieve it, run predictions, or promote it to a downstream inference job – all without ever seeing your notebook.

Let's visualize the holdout. Run the final cell of the notebook:

Here's what the code does:

You should see the two lines tracking each other reasonably closely. The fit has room to tune, and you've built a working forecaster end to end in a fraction of an hour.

Duration: 5

Data science and machine learning work often involves the use of source control and git repositories. The suggested path for working with repos using remote development is to clone them into the /mnt/pd0 directory. This is the persisted storage directory, and cloning into it will ensure that the repo will be available to you in subsequent SSH sessions.

Git authentication is typically handled by your editor's GitHub sign-in – no secret or credential helper needed. If your remote VS Code (or Cursor) session is signed into GitHub, many git operations will work with little to no configuration.

To quickly check if you are logged into GitHub, do the following:

1. Click on the Accounts icon in VS Code (or Cursor) in the remote window.

2. If you see something like "your-username (GitHub)", then you're signed into GitHub.

If you're signed in, then the typical git clone workflow applies and automatically works for repos that you own or have been added to as a collaborator:

If you are running git under a service identity instead of your own, store an access token in a Snowflake secret, mount it into the service, and point git at it with a credential helper. This is the common pattern for team and production environments. For details, see Remote Development with the Snowflake Extension for Visual Studio Code.

Before your first commit in this repo, git needs an author identity. Set it at the local repo level using --local to persist your git identity from session to session. Using --global will write the config to /root, which is wiped on session suspend. Local config lives in the repo on /mnt/pd0 and persists:

Duration: 2

Let's confirm your work survives a suspend.

1. Save any unsaved files. In the Remote Environments panel, stop the tb_forecast_env environment and close the remote window. The environment status will flip to SUSPENDED.

2. Resume the service and pick the same workspace when connecting.

3. In the terminal on the remote, confirm your files are intact:

Everything under /mnt/pd0 – the repo, your pip installs – is exactly as you left it. /root is empty: it's the ephemeral filesystem, wiped on suspend. The registered model persists in Snowflake regardless (run SHOW MODELS IN SCHEMA tb_101.ml; for example).

Duration: 2

When you're done, tear everything down. Do it in this order, because the cleanup script drops the compute pool the remote service runs on – so the service has to go first.

1. Delete the remote service. In VS Code, in the Remote Environments panel: stop the remote environment and then delete it.

2. Drop the Snowflake objects. From the companion repo, run cleanup.sql with the Snowflake CLI (or paste its contents into a Snowsight worksheet):

That script:

Duration: 1

Congratulations! You built and shipped an end-to-end ML workflow – data ingest, feature engineering, model training, and registry logging – entirely against Snowflake compute, from your local editor, without provisioning a VM, managing an SSH key, or moving a single row down to your laptop.

The same remote environment that ran this notebook can host your team's other ML projects. The same Model Registry entry can be picked up by inference services, scheduled tasks, or downstream teammates. And the same editor you already work in – VS Code or Cursor – is now a first-class interface to Snowflake's compute plane.