When deploys become routine,
script them
Drop files in the browser for the first proof. When the same static build ships again and again, move the release step into your terminal, CI job, or playbook so publishing stops depending on someone remembering the upload.
For releases you do more than once
Stop relying on manual memory
A deploy command turns a repeated upload into a release step the team can document, review, and run the same way.
Let CI finish the job
If GitHub Actions or another CI system already produced the build output, the deploy step should publish that folder without a human re-uploading files.
Keep the same project model
Start with browser upload, then move the same project into automation when it becomes a real release path.
Manual first, automation when it earns its place
One-off previews should stay simple. CLI deploys become attractive when a site is shipped repeatedly, reviewed by a team, or triggered by a build pipeline.
steps:
- uses: actions/checkout@v2
- run: npm install && npm run build
- run: npx @deploypages/cli deploy ./dist --token ${{ secrets.DEPLOY_TOKEN }}Frequently asked questions
Q: Can this run on Windows, macOS, and Linux?
Yes. A useful CLI deploy path has to fit the operating systems teams already use for local builds and CI runners.
Q: Can I target a specific project from automation?
Yes. Scriptable deployment only works well when teams can explicitly bind a release flow to the right project context.
Q: Does this fit monorepos?
Yes. Teams with monorepos need a deployment path that can target specific working directories and release outputs cleanly.
Start from the part every static site already has
Upload the built files, get a live HTTPS link, then add domains, rollback, analytics, automation, and team control when the project needs them.