Deploying Flutter Web with GitHub Actions without installing Flutter on the production server

[u/MohammadMahdiDev]

I wanted to deploy a Flutter Web app without installing Flutter on the production server.

So I split the process into two parts:

1. Build on GitHub Actions

When I push to main, GitHub Actions:

• Checks out the code
• Installs a specific Flutter version
• Runs flutter pub get
• Runs flutter build web --release
• Uploads build/web as an artifact

2. Deploy on my server

A self-hosted runner on my server downloads the artifact and copies the files to the Nginx directory using rsync.

So the production server only receives the final static files. It does not need Flutter installed, and it does not need to pull the source code.

The main distinction:

• Workflow defines what should run.
• Runner is the machine that runs it.
• In this setup, the build runs on GitHub’s runner, while deployment runs on my self-hosted runner.

This keeps the build environment separate from production and makes deployment repeatable.

One thing I learned: don’t forget security. Use GitHub Secrets for SSH credentials, give the runner only the access it needs, and avoid running untrusted workflows on a runner that can reach production.

Would you deploy Flutter Web this way, or do you prefer building directly on the server?

[u/kokerali]

I'd keep building in CI. One thing to check in the deploy job is whether an older, slower workflow can overwrite a newer release. Tie the downloaded artifact to the producing run/commit and use a shared production concurrency group. GitHub documents that concurrency limits simultaneous jobs, but execution order is not guaranteed, so I'd also check whether that commit is still eligible for promotion before changing the live release.

For the rsync step, I'd copy into a separate release directory, verify it, then switch which release Nginx serves, retaining the previous one for rollback. Two useful checks: interrupt the copy halfway and confirm the current site still loads; deliberately finish two builds out of order and confirm the older one can't become live. Those would tell you more about deployment safety than a successful copy alone.

[u/MohammadMahdiDev → u/kokerali]

Good point. I'll keep builds in CI and tighten the deployment process by pinning artifacts to their run and commit, adding production concurrency controls, and checking commit eligibility before promotion.

I'll also look into atomic release switching with Nginx and rollback support, then test interrupted copies and out-of-order builds.