Skip to main content

Pre-build SSH command for change detection and early abort

Feature Request

Summary Add the ability to run a server-side SSH command as the very first step in the deploy chain — before the build process runs — so that deployments can be aborted early based on the state of the remote server.

Background We use DeployHQ to manage deployments and keep environments in sync across all of our client projects. A recurring challenge is that clients sometimes make changes directly on their live sites (e.g. configuration tweaks, content updates, plugin/theme adjustments). When that happens, we need to pull those changes down before deploying, otherwise our deploy will overwrite the client's work.

The problem Today, the earliest hook we have for running a server command is the Pre-deployment command, which only fires after the build process has completed. This means:

  • We can't check the state of the server before spending time and resources on a build.

  • If we detect changes that need to be downloaded first, we've already wasted a full build cycle.

  • Aborting at that point is later than ideal in the workflow.

Proposed solution Introduce a new step at the very beginning of the deploy chain — for example, a "Pre-build SSH command" — that runs against the target server before the build kicks off. This command could:

  • Detect uncommitted or out-of-sync changes on the remote site.

  • Exit with a non-zero status to abort the deploy cleanly and early, before any build runs.

  • Optionally surface a clear message in the deploy log explaining why the deploy was halted.

Benefits

  • Saves build minutes and compute on deployments that shouldn't proceed.

  • Keeps the existing Pre-deployment command intact for steps that genuinely need to run after the build.

Posted by Ola Lundén ·
Status: Completed3 comments

Log in to comment and vote

Comments3

  • Facundo@DHQ

    Team•

    May 13

    Hey Ola,

    Thanks for the detailed write-up — you've articulated the problem clearly, and the pain point is real. Running an entire build cycle just to discover the deploy needs to be aborted is
    wasteful, especially when the signal is sitting right there on the target server.

    We're scoping this as something broader than a single pre-build SSH command: a typed "deployment checks" feature with both pre-build and post-deploy validations. The pre-build variant gates the build (exactly what you've described), and the post-deploy variant runs after the transfer completes — for example, an HTTP check to confirm the site responds with a 200 from outside the server. Both would support SSH commands and HTTP checks, with structured pass/fail in the deploy log rather than just shell output.

    Your drift-detection scenario fits naturally as a pre-check. For your setup, with git on the target, the command would be as simple as:

    git diff --quiet && git diff --cached --quiet || exit 1

    Non-zero exit aborts cleanly before any build resources are spent.

    A couple of questions to help us scope v1 correctly:

    • Beyond drift detection, what other pre-build checks would you want to run? Disk space, maintenance-mode flags, lock files, anything else?

    • For post-deploy, what would you want to verify? Smoke tests, app-specific health endpoints, queue state, etc.?

    The more concrete examples we have from your day-to-day, the more confident we'll be that v1 covers the right ground rather than just the obvious surface.

    Reply whenever you've had a chance to think it through — no rush.

    Best,

    DeployHQ Team

    • Ola Lundén

      •

      May 13

      Hey!

      Thanks for quick feedback!

      Most of our sites are built using Drupal as a platform, so today we check if there are any config changes by running this command:

      cd %current_path%/scripts && chmod u+x ./config-check.sh && ./config-check.sh


      So if we could run these type of commands as the first part of the deploy that would be great!

      The command git diff --quiet && git diff --cached --quiet || exit 1 would also come in handy for some of our sites running git on the server.

      • Facundo@DHQ

        Team•

        May 18

        Hey — just shipped this, actually. Deployment Checks went live today.

        A pre-build SSH check is exactly what you described: an arbitrary command run against your server before the build pipeline starts, with a non-zero exit cleanly aborting the deploy (no build resources spent, no half-deployed state, no overwritten changes).

        The docs walk through the change-detection use case as the first worked example:

        git diff --quiet && git diff --cached --quiet || exit 1

        If anything is uncommitted on the target server, the deploy aborts before it kicks off.

        Full guide here: https://www.deployhq.com/support/deployments/deployment-checks

        A couple of things worth flagging:

        • Deployment Checks are currently in beta — toggle beta features on your account to see the entry in the project sidebar.

        • HTTP checks are also supported (handy for hitting a /maintenance.json flag, a healthcheck endpoint, or any URL-based signal), and they work for non-SSH project types too — FTP, ElasticBeanstalk, Heroku, cloud-storage.

        • We also shipped a vulnerability_scan check type (Snyk / Trivy) under the same beta flag, in case scanning the build source pre-build is interesting alongside drift detection.

        Would love to hear how it goes once you've kicked the tyres — happy to iterate based on what you run into.