Deploy a Website Straight From VS Code to Your Host

You can deploy a website straight from VS Code using one of three approaches: an SFTP extension for drag-free file sync, an SSH terminal for running commands on the server, or Git with a post-receive hook for a proper push-to-deploy flow. For most solo builders the sweet spot is Git for anything real, and SFTP for quick static sites.

The reason people are ditching FileZilla and the like is simple: switching windows to hunt for the file you just edited is a waste of your day. Everything below happens inside the editor you already have open. Nothing here needs a paid extension.

The one rule to internalise before you touch anything: never edit files directly on a live server, and never sync your whole project folder blind. That is how you overwrite a config file or wipe a directory someone else was using. We'll build a workflow that makes that mistake hard to make.

Which method should you actually use?

Pick SFTP for static sites and quick edits, SSH for running server commands, and Git for any site you'll update more than a handful of times. These are not mutually exclusive — most people end up using two of them.

Here's the honest breakdown so you don't overthink it:

My position: if you're going to maintain the site past next week, spend the ten minutes on Git. The ability to roll back a bad deploy with one command pays for the setup the first time you fat-finger something.

Set up SFTP inside VS Code

To deploy over SFTP, install a sync extension, drop a config file with your server details in your project, and upload only the folders you choose. The popular free option is SFTP by Natizyskunk (a maintained fork of the classic liximomo extension).

After installing, open the command palette (Ctrl/Cmd + Shift + P), run SFTP: Config, and you'll get a .vscode/sftp.json file. Fill it in like this:

• host — your server hostname or IP
• username — your SSH/SFTP user
• remotePath — the exact live directory, e.g. /home/youruser/public_html
• uploadOnSave — set this to false until you trust the setup
• privateKeyPath — point to your key instead of using a password

Two settings save you from disaster. First, add an ignore list so you never push local junk: [".vscode", ".git", "node_modules", ".env"]. Second, leave uploadOnSave off at the start — upload manually by right-clicking a file and choosing Upload. Auto-upload-on-save is fine once you're confident, but it will happily push a half-finished file the moment you hit Ctrl+S.

Keep your sftp.json out of version control if it contains any secrets — add .vscode/sftp.json to your .gitignore.

Use the SSH terminal for real work

The integrated terminal in VS Code is a full shell, so ssh youruser@yourserver gets you onto the box without leaving the editor. This is where you run builds, clear caches, or restart a service after a change.

Better still, install the official Remote - SSH extension. It opens a VS Code window that runs entirely on the server — you edit remote files with full IntelliSense, the terminal is already on the machine, and there's no upload step because you're working there directly. For a VPS this feels close to magic the first time.

A word of caution that applies to any remote shell: know which directory you're standing in before you run anything destructive. Before a command that deletes or moves files, run pwd and ls first. On a TPC VPS you get root access, which is exactly what you want for this kind of control — and exactly why a careless rm -rf hurts. Slow down on that one command.

The proper way: Git push-to-deploy

The cleanest workflow is pushing your code to a bare Git repo on the server, which then checks out the files into your web directory automatically. You deploy by typing git push live from VS Code's source control panel or terminal. No files get overwritten by accident because Git only touches what changed.

SSH into your server once and set up the bare repo plus a hook:

• Create the repo: mkdir -p ~/site.git && cd ~/site.git && git init --bare
• Create the hook file hooks/post-receive with: git --work-tree=/home/youruser/public_html --git-dir=/home/youruser/site.git checkout -f
• Make it executable: chmod +x hooks/post-receive

Back in VS Code, add the server as a remote: git remote add live youruser@yourserver:site.git. Now every git push live main checks your latest commit out into the live directory. Because it's a checkout of tracked files, anything not in Git (uploaded user images, a server-side .env) stays untouched.

Want a build step — say, a static site generator or a bundler? Add the build command to the same post-receive hook after the checkout. And rolling back a bad release is one command on the server: check out the previous commit hash into the work tree, done in seconds.

How to never overwrite your live files

The safest habit is to treat the live server as read-only for humans and write-only for your deploy tool — you push to it, you don't hand-edit it. Combine that with a small pre-flight checklist and overwrites stop happening.

Run through this before any deploy:

• Confirm your remotePath or work-tree points at the right site (double-check on a server with multiple domains)
• Keep secrets and config in a server-side .env that's in your ignore list — never sync it from local
• Never sync user-generated folders like /uploads or /wp-content/uploads back down or up blindly
• Back up before a big change: a quick tar -czf backup-$(date +%F).tar.gz public_html costs seconds
• Test on a staging subdomain first if the change is anything more than cosmetic

For anything you can't afford to break, deploy to a staging directory, look at it in a browser, then swap. With Git you can point a staging remote at a separate folder and a separate subdomain — same push flow, no risk to the live site.

If you're moving an existing site onto a new host to do this properly, TPC Hosting migrates it for you free, and there's a 30-day window to back out if the setup isn't clicking. Real engineers are on support around the clock if your post-receive hook won't fire — send them the hook and the error, they'll spot it fast.

A sensible default setup

For a typical solo project, use Git push-to-deploy for the code, keep an SFTP config for emergency one-file fixes, and keep secrets in a server-side .env. That covers speed, safety and rollbacks without any paid tooling.

Everything here works the same on shared hosting and on a VPS, as long as you have SSH access. On TPC that's included on the plans built for developers, EU-hosted and GDPR-friendly so your deploy target and your data stay in the same jurisdiction as your customers.

FAQ