A VS Code Extension That Zips, Uploads, and Deploys to Linux Servers in One Click

Frontend project deployment looks like just building and then uploading the dist folder to the server.

In practice, you have to open a terminal, connect via SFTP, locate local and remote directories, and confirm that config files, old resources, and user-upload directories haven't been accidentally touched.

When you have many projects and servers, these repetitive operations are not only annoying but also prone to uploading to the wrong directory, overwriting online configurations, or deleting files that shouldn't be deleted.

I've been frustrated by this process many times, so I built a VS Code extension called Simple Deploy.

What problem does it solve

Simple Deploy saves server info, project paths, upload rules, and deployment commands inside VS Code.

When a project needs updating later, you don't need to leave the editor or dig up server addresses and directories each time. After confirming the rules, one click deploys it.

It doesn't aim to replace a full CI/CD platform.

It's better suited for this need: you have a Linux server, and after making changes to a project, you want to push this prepared version online quickly and reliably.

Before, manual deployment usually followed this flow:

Edit code
↓
Run build command
↓
Open SFTP tool
↓
Enter server username and password
↓
Find local and remote directories
↓
Drag files to upload
↓
Confirm which files cannot be overwritten
↓
Manually delete old files
↓
Refresh the page to verify

Simple Deploy consolidates this repetitive flow.

You just need to specify in advance which server to push to, which directory, what to upload, what to delete, what must not be touched, and what to do before and after deployment.

Code, build commands, and Git are all inside VS Code. Bringing deployment in as well makes the whole workflow more coherent.

Which projects can use it, and how to start

As long as a project can be published to a Linux server via files and can be started, restarted, or updated using server commands, it's suitable for Simple Deploy.

It can deploy many types of projects, commonly including:

• Vue, React, Vite, and other frontend projects
• VitePress, VuePress, and other documentation sites
• Official websites, event pages, product landing pages
• Admin panels and mini-program H5 pages
• Pure HTML, CSS, JavaScript websites
• Node.js, Java, Python, Go, and other backend projects
• Frontend packages, backend packages, or config files for projects with separated frontend and backend

If you maintain a personal blog, portfolio, or product website and want to quickly update the site after editing content, it's suitable.

If you're doing outsourcing or small-team projects and need to maintain multiple client servers, it's also suitable.

If you have testing and production environments, you can create two deployment configurations for the same project. Deploy to the test server when needed, and after confirming everything is fine, deploy to the production server.

The whole process is not complicated. First, add a server, filling in the name, address, port, username, and password.

Server names can be written according to your own habits:

Test Server
Production Server
Hong Kong Official Website Server
Client A Admin Server

Then add project rules. The most common configuration for a frontend project is roughly:

Project Name: My Website
Target Server: Production Server
Remote Path: /var/www/my-site
Upload Rule: dist/**

dist/** means uploading the contents of the locally built dist directory to the server.

When a project needs building, you can add commands like bun run build to the Pre-commands. Deployment will build first, then upload files.

The same goes for backend projects. After uploading build artifacts or project files, restart the service via Post-commands.

For example, a Node.js project can upload built files and then execute pm2 restart my-app.

A Java project can upload the JAR package and then execute the corresponding application restart command.

Python or Go projects can also configure post-commands according to their own startup methods.

Rules and commands

Simple Deploy's boundaries are very clear.

Upload rules determine what to upload, Delete rules determine what to delete, Retain rules determine what must absolutely not be touched, and Pre- and Post-commands determine what to do before and after deployment.

Most frontend projects only need one upload rule:

dist/**

After deployment, the local dist/index.html and dist/assets/app.js will become index.html and assets/app.js on the server.

When you don't want to upload a certain file, you can use Exclude rules:

dist/**
!dist/config.json

Simple Deploy only overwrites by default and will not delete server files on its own.

Online directories often contain user images, environment configs, and historical data that don't exist locally. These cannot be automatically deleted by a tool just because they are absent from the local project.

When you really need to clean up historical content, explicitly write Delete rules:

legacy/**
old-version.html

Old files are backed up before deletion.

And critical online content like config.json and uploads/** can be added to Retain rules.

Local files with the same name will not overwrite them, and delete rules will not delete them.

A common website rule configuration can look like this:

Upload Rule: dist/**
Delete Rule: legacy/**
Retain Rule: config.json, uploads/**

This means updating the latest build files, cleaning up the historical legacy directory, but leaving online configs and user-uploaded files completely untouched.

Pre-commands execute locally and are suitable for building, compiling, generating configs, or compressing resources.

If any Pre-command fails, deployment stops, preventing unprepared files from being sent to the server.

Post-commands execute on the server and are suitable for restarting backend services, reloading Nginx, or clearing caches.

Post-commands execute in order. Failures are recorded in the deployment log, but successfully published files are not automatically rolled back.

Why it's fast, and why not rsync

After a frontend project is built, it often generates hundreds of small files.

Simple Deploy doesn't upload these files to the server one by one. Instead, it first compresses them into a single ZIP package according to the rules, uploads this one package, and finally the server decompresses it locally.

The network only needs to transfer one contiguous file, and the server handles decompression locally. The more files there are, the more time is saved compared to uploading them individually.

rsync is very mature and suitable for continuously syncing directories and massive numbers of files.

But resource files in frontend build artifacts often carry hash suffixes. Each build generates a large number of new filenames, significantly weakening rsync's incremental advantage.

When you need to continuously sync massive numbers of files, rsync remains a great choice.

When you need to publish a prepared project version from within VS Code, Simple Deploy is more direct.

Deployment experience and supported platforms

Simple Deploy displays a complete deployment log, including pre-commands, build time, compressed package size, upload time, deployment time, post-commands, and total time.

When builds, connections, uploads, or server commands fail, the log also retains specific information.

Project size, server location, and file count all affect deployment time.

ZIP uploading reduces the network transfer operations for many small files, but what Simple Deploy truly saves is manual operation time.

Before, one deployment usually went like this:

Operation	Typical Time Spent
Execute build, confirm build log	1 to 3 minutes
Open SFTP, connect to server, find directory	About 1 minute
Drag files, wait for upload, check files	2 to 5 minutes
Manually handle old files and config files	1 to 3 minutes
Total	5 to 12 minutes

Now the manual part is usually just confirming rules and watching the results.

If you deploy 5 times a day, saving 4 minutes of manual work each time, that's roughly over 6 hours saved per month, not counting the troubleshooting time after uploading to the wrong directory, overwriting the wrong config, or forgetting to delete old files.

Simple Deploy is a VS Code extension. The development environment supports Windows, macOS, and Linux.

The deployment target is a Linux server, such as Ubuntu, Debian, CentOS, and AlmaLinux.

As long as the server can be logged into via SSH and can run the project, it's basically sufficient.

Final words

There's no shortage of deployment tools on the market. SFTP, rsync, and CI/CD platforms are all great.

But what I wanted was a deployment entry point inside VS Code, with clear rules, that doesn't randomly delete files by default.

What Simple Deploy aims to do isn't big. It's just turning the act of publishing a project to a server from a series of repetitive operations into a clear, confirmable, repeatable process.

I suggest trying it first with a test project, like a Vite project or a documentation site.

First configure dist/**, confirm the deployment works normally, then gradually add retain rules and delete rules.

If you also maintain websites, documentation sites, admin panels, or backend projects and often need to send files to a Linux server, give Simple Deploy a try.

I wonder how you usually deploy your projects?

Feel free to leave a comment.

Thanks for reading. I am Chen Suiyi, the Frontend Tiger. Public account 陈随易, personal website: https://chensuiyi.me.