Best Practices for Deploying Flutter Web
When deploying a website or web application to a production server, understanding how to work safely is essential.
In the Linux/UNIX world, there are long‑established “safe operation practices” that help prevent mistakes. Learning these practices greatly reduces anxiety when working with production environments.
This article summarizes simple and safe deployment techniques using SSH, rsync, and vim, with Flutter Web as the example.
1. Shorten SSH Commands with ~/.ssh/config
Typing the IP address and username every time is tedious. You can register your server in the SSH config file.
Host myserver
HostName 123.123.123.123
User username
IdentityFile ~/.ssh/id_ed25519
This allows you to shorten commands like:
- ssh myserver
- scp file myserver:/path/
- rsync ./local/ myserver:/path/
- sftp myserver
All SSH‑based commands automatically use this configuration.
2. Build Flutter Web Artifacts
Flutter Web outputs its production files into build/web/.
flutter build web
These files can be deployed to the server as‑is.
3. rsync Is the Best Tool for Production Deployment
To deploy to production, use rsync. The rsync command always takes the form local → server.
rsync -avz ./build/web/ myserver:/var/www/html/
Benefits of rsync
- Uploads only differences (fast)
- Automatically creates directory structures
- Preserves permissions
- Uses your SSH configuration
The Importance of the Trailing Slash
web/→ uploads only the contents (recommended)web→ uploads the folder itself (may cause unexpected directory structures)
4. About Excluding Files (exclude)
rsync supports excluding files and directories, similar to .gitignore.
For example, to exclude .git/:
rsync -avz --exclude='.git/' ./local/ myserver:/var/www/html/
You can also use --exclude-from to load multiple patterns from a file.
However, Flutter Web deployments normally do not require exclude rules because build/web/ contains only static assets needed for production.
There are no development‑only files mixed into the output, so you can safely deploy the entire directory.
5. Use dry-run for Safe Verification
The -n option performs a dry run—a test execution that transfers nothing.
rsync -avzn ./build/web/ myserver:/var/www/html/
This lets you verify:
- Which files will be uploaded
- What will change
- Which files differ
Dry runs are essential for safe production deployments.
6. For Small Fixes, SSH + vim Is Simple and Powerful
For quick edits, logging into the server and using vim is often the fastest approach.
ssh myserver
cd /var/www/html/
Always Create a Backup Before Editing
Before editing a production file, always create a backup:
cp index.html index.html.bak
This is a “pre‑edit snapshot” that preserves the original state.
Keep this .bak file as-is and do not overwrite it after editing.
If you overwrite the backup, you lose the ability to restore the pre‑edit state. Keeping the original .bak for a while is the safest approach.
Editing
vim index.html
Restoring If Something Goes Wrong
cp index.html.bak index.html
This restores the file to its pre‑edit state.
7. When to Use rsync and When to Use SSH + vim
| Use Case | Method | Reason |
|---|---|---|
| Production deployment | rsync | Fast, safe, differential upload |
| Small fixes | SSH + vim | Immediate and simple |
| Safety check | dry-run | Prevents mistakes |
| Restore point | cp file file.bak | Allows rollback |
Summary
- Shorten SSH commands with
~/.ssh/config - Deploy
build/web/as-is - Use rsync for production deployment (with dry-run)
- Pay attention to the trailing slash
- Exclude rules exist but are rarely needed for Flutter Web
- Use SSH + vim for quick fixes
- Keep the “pre‑edit .bak” file and never overwrite it
Understanding these practices will help you deploy with confidence and avoid common production mistakes.