GitHub deploys
Connect your GitHub account and deploy any repository from the dashboard. Ready-to-serve sites go live at once; framework projects get a build pipeline Dplooy sets up for you. Every plan.
Deploy a repository
- 1On your dashboard, click Deploy from GitHub under the drop zone.
- 2Connect your GitHub account in the window that opens. Dplooy asks for access to read your repositories, and to add a workflow file only if you choose the build pipeline — nothing is written to your repo otherwise.
- 3Pick a repository on the Available tab. Repositories you have already deployed sit on Already deployed, so you can't overwrite a site by accident.
- 4Choose the branch, optionally a root directory such as
dist/if your built files are committed, and a project name. Then deploy.
Private repositories work too. A repository you have already deployed is managed from the site itself: open it and choose GitHub under Deploy.
Projects that need a build
React, Vite, Astro, Nuxt, SvelteKit, Angular and other framework source isn't a website until it is built. When Dplooy sees one, it says This project needs a build, reads your package.json and suggests a build command and output folder — both editable.
- 1Click Set up build & deploy, check the command and folder, then Confirm & set up.
- 2Dplooy commits
.github/workflows/dplooy.ymlto your repository and adds a Dplooy key as the encryptedDPLOOY_API_KEYrepository secret. - 3The build runs on GitHub's servers and the output deploys to Dplooy automatically, with live build status in the dialog. Every later push builds and deploys again.
Setting up the pipeline adds a commit on GitHub, so your local copy is one commit behind. Run git pull before your next push, or Git will reject it.
- Next.js needs
output: "export"innext.configbefore it can be hosted as static files. - To turn the pipeline off, remove it in the site's GitHub settings, or delete
.github/workflows/dplooy.ymlfrom the repository. - A site built by the pipeline is edited in the repository, not in the Visual or Code Editor — the next push would overwrite the edits.
Deploy on every push
For a ready-to-serve repository, open the site's GitHub settings, go to the Deploys tab and turn on Deploy on every push. Dplooy adds a webhook to the repository — no files change there — and redeploys the same address on each push.
To update by hand, click Redeploy now on the same tab to pull the latest commit, or Rebuild & deploy on pipeline projects. Pipeline projects already deploy on every push, so they don't show the toggle.
Write your own GitHub Actions workflow
Most repositories never need this. For full control, create a key under Settings → API Keys, add it to the repository as a secret named DPLOOY_API_KEY, and commit a workflow that zips the site and sends it to the API:
name: Deploy to Dplooyon: push: branches: [main]jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Deploy run: | zip -r site.zip . -x ".git/*" ".github/*" curl -X POST https://api.dplooy.com/api/v1/deploy/zip \ -H "Authorization: Bearer ${{ secrets.DPLOOY_API_KEY }}" \ -F "name=${{ github.event.repository.name }}" \ -F "file=@site.zip"
- The same project name updates the same address, and analytics carry on.
- Don't name your file
dplooy.yml— that name is kept for the workflow Dplooy manages. - Don't also turn on Deploy on every push for the same site, or each push deploys twice.
- Need a build? Add
npm ci && npm run buildbefore the zip step and zip the output folder instead.