Deployment.sh

Deploy from git to your own servers with one push

The simplest deploy workflow is the one your team already uses: commit, push, done. Deployment connects your repository on GitHub, GitLab, Bitbucket or any git server, maps branches to environments and turns every push into a release on your own servers, built in a fresh folder, checked and switched with zero downtime.

Developer sketching branch lines on a window with a grease pencil in a cramped loft workspace at night, laptop and bike in the background

Why git pull on the server is not a deploy

Many teams start with a script that SSHs in, runs git pull and restarts something. It works, until a pull leaves the working tree half updated while dependencies install, until a local change on the server blocks the merge, or until a broken commit goes live and the only way back is another commit. There is no record of who deployed what, and the server's working copy slowly drifts from the repository.

How Deployment turns a push into a release

Deployment never edits a live working copy. Each deploy clones the exact commit into a new release folder, links shared paths such as storage and the env file, runs your build steps, runs a health check and only then points the current symlink at the new release.

  • The exact commit SHA is recorded with the author, branch, duration and full log
  • A failed build or health check leaves the running release untouched
  • Rollback switches back to any kept release in one click
  • Learn why this matters on zero downtime deployment
Backend developer at a desk at night watching deploy logs scroll in a dark terminal on two monitors

Connect GitHub, GitLab, Bitbucket or any git URL

Connect GitHub, GitLab or Bitbucket with an OAuth app or an access token and pick repositories from a list. For self-hosted Gitea, GitLab instances or any other server, use the SSH URL and add the deploy key Deployment generates for that site, read-only on your side.

  • Private repositories through deploy keys or provider apps
  • Monorepos with a root folder per site, so an API and a frontend deploy separately from one repository
  • Git submodules and Git LFS supported in the build step

Branch per environment

Each site has one or more environments, and each environment follows a branch. A typical setup is main to production and develop to staging, but you can map any branch, including release branches or a branch per client.

  • Separate env variables, domains and workers per environment
  • Optional manual approval for production, so a push to main waits for a click
  • Deploy a specific commit or tag from the panel when you need to

Push to deploy through a signed webhook

When you connect a repository, Deployment registers a webhook with your git host. Every push sends a signed event, Deployment checks the signature and the branch, and queues a deploy. If you prefer to control the trigger from CI, turn the webhook off and call the deploy URL or the CLI after your tests pass, as described on continuous deployment software.

bash 
deployment deploy --site api --env production --commit "$GITHUB_SHA"

A deploy script you can read and edit

Deployment detects the stack from the repository and writes a starting deploy script. You can edit every line. Here is what a detected Laravel site starts with.

  • Variables for the release path, shared path, commit and branch are available in every script
  • Hooks before and after the symlink switch for cache warmups or notifications
bash 
cd "$RELEASE"
composer install --no-dev --prefer-dist --optimize-autoloader
npm ci && npm run build
php artisan migrate --force
php artisan config:cache
php artisan route:cache

Stack auto-detection from the repository

Deployment reads manifest files to propose runtimes, build commands and processes: composer.json and artisan for PHP and Laravel, package.json with next, nuxt, express or vite for Node.js, requirements.txt, pyproject.toml and manage.py for Python, Gemfile for Rails, go.mod for Go, pom.xml or build.gradle for Java, csproj files for .NET and Dockerfile or compose files for containers. Try it on any public repository with the demo on the home page.

Deploy from git for every stack

Laravel, Symfony and WordPress, Node.js and Next.js, Django and FastAPI, Rails, Go, Spring Boot, ASP.NET Core, static sites and Docker all follow the same git workflow. The rest of the platform is on software deployment automation.

Which plan fits your git workflow

Every plan includes push to deploy, branch per environment and rollback. Starter is 49 USD a month or 24 USD billed yearly for 3 servers and 15 sites with 14 days of deploy history. Team is 199 USD a month or 99 USD yearly with 90 days of history and 10 members. Agency is 499 USD a month or 249 USD yearly with 1 year. Enterprise is 1 499 USD a month or 749 USD yearly with 2 years. See PaaS pricing.

See pricing

Does Deployment need write access to my repository?

No. Read access is enough to clone. Write access is only used, if you allow it, to register the push webhook automatically.

Can I deploy without a webhook?

Yes. Deploy from the panel, the API, the CLI or a CI job, and leave the webhook disabled.

What if two pushes arrive at once?

Deploys for one environment run one after another. If a newer push arrives while an older one is queued, the older one is skipped so the latest commit wins.

Can I try Deployment before I pay?

Yes, with the free one-time demo on the home page. Plans start at 49 USD a month, or 24 USD a month billed yearly.

Make git push your deploy button

Connect a repository and ship your next commit with a health check and a rollback ready.

Paste a public repository URL and Try the demo.