Deploy without
taking your app offline

Zero downtime deployment means your application stays live while new code is deployed. Pushdeck clones each release into a separate folder and uses a single symlink swap to activate it. Your users never see a broken state or maintenance page.

No. Pushdeck works with any language or framework. It clones your repository, runs your deployment hooks, and swaps the release symlink. What you put in those hooks is entirely up to you. Run npm ci && npm run build for a Node.js app, bundle exec rails db:migrate for Ruby on Rails, go build for Go, or anything else your stack needs. As long as your server runs Linux and you can deploy over SSH, Pushdeck handles the rest.

Yes. Pushdeck works great with Laravel. Run composer install, php artisan migrate, and php artisan queue:restart as deployment hooks before or after each release is activated.

Pushdeck supports GitHub and GitLab. Connect any public or private repository using a personal access token and deploy any branch.

Yes. Every project gets a unique deploy webhook URL. Call it from GitHub Actions, GitLab CI, or any HTTP client to trigger a deployment automatically on every push.

Yes. Connect a Slack Incoming Webhook to get a message in your channel the moment a deploy succeeds or fails, including the commit, who triggered it, and how long it took. You can also point a generic webhook at any URL to receive a JSON payload for every deployment and wire it into your own tooling.

Yes. Invite teammates by email and assign each person a role: Admin, Deployer, or Viewer. You can fine-tune individual permissions per person and per project, so someone can be an admin on one project and view-only on another. Invitations are accepted explicitly, and members can be removed or can leave at any time.

Yes. Previous releases stay on disk. Roll back to any successful deployment with one click. Pushdeck re-activates the old release and re-runs any hooks you placed after activation, so post-deploy steps like cache clears and service restarts still happen. The switch is near instant because nothing has to be re-cloned.

Your live site stays up. Pushdeck clones and runs your build hooks into a brand new release folder and only switches the current symlink once that work succeeds, so a failure before activation never touches the running release. When a step fails, the deployment stops and every remaining step is marked failed so you can see exactly where it broke.

Yes, if you set them as Linked Folders. Each deploy clones a fresh copy of your code, so anything written at runtime would normally be lost. Folders you mark as linked (like storage or public/uploads) live in a shared directory and are symlinked into every new release, so user uploads, logs, and sessions persist across deploys and rollbacks.

Any Linux server you can reach over SSH. DigitalOcean, Hetzner, AWS EC2, Linode, Vultr, your own VPS. If you have SSH access and a deploy path, Pushdeck works with it.

You stay in full control at every level. For your repository, Pushdeck only needs a read-only personal access token scoped to a single repo, so it can clone your code and nothing else. For your server, Pushdeck connects over SSH using a key it generates for you. You add that public key to your server and can delete it at any time to immediately revoke access. You can also restrict that key to a specific user with write access to only your project folder, so Pushdeck cannot touch anything else on the machine. Your environment variables are encrypted with a key only you know, and that key is never saved to our database, session, or logs. Pushdeck follows industry standard security practices and you are always in control of both your code and your infrastructure.

No. Your code is cloned directly onto your own server over SSH, pulled straight from GitHub or GitLab during each deployment. Pushdeck orchestrates the process but never holds a copy of your repository on its own servers.

The encrypted copy stored in Pushdeck cannot be recovered, because your key is never saved anywhere. Your app keeps running normally though, since the plaintext .env was already written to your server at deploy time. You can simply set a new environment key and save your variables again to restore editing.