We’re happy to announce that we’ve made the move from DeployBot to DeployHQ. Why does this matter to our clients? Alex Ryans, our Lead Front-End Developer, explains…
Background: A Solid but Aging Setup
For years, DeployBot handled about 95% of our deployments. The rest were handled via Bitbucket Pipelines or directly through our hosting provider. Our setup followed a common structure: deploy to staging automatically on commit, then manually deploy to production once everything checks out. Along the way, we’d install dependencies, run builds, symlink directories, set permissions, and restart services.
Over time, though, DeployBot started to feel sluggish.
“The UI became slower, and deployment times were longer than they should’ve been – especially on cold servers,” Alex shared.
While it still got the job done, we knew we’d need a better solution eventually.
Why DeployHQ?
We’d already been considering a move to DeployHQ, and the announcement of the DeployBot–DeployHQ merger gave us a push to revisit it.
“We were lucky the timing worked out, it meant we didn’t have to do two migrations,” Alex said.
The appeal of DeployHQ was immediate: a faster interface, improved deployment speeds, and better visibility into each deployment. Plus, a few team members had already used DeployHQ on other projects.
How the Migration Worked
Despite dozens of projects to move over, the migration process went better than expected. With help from the DeployHQ team, we were able to migrate jobs in small batches and test each one before moving on.
“The process was incredibly smooth,” Alex said. “The DeployHQ Team helped guide things from start to finish, and they were quick to respond when we had questions.”
Still, there were a few speed bumps:
- SSH Variable Differences: DeployBot used
$RELEASE, while DeployHQ uses%release_path%. That required some manual updates to commands. - Teams Integration: DeployBot allowed a single webhook setup across all projects. In DeployHQ, each project needed its own Teams integration. “It wasn’t a dealbreaker, but it added a bit of repetitive setup.”
- Server Groups: DeployHQ automatically creates Server Groups, but the client preferred to manage servers manually, so we had to do a bit of cleanup.
Deployment Workflow (Post-Migration)
Once everything was moved over, the actual deployment process didn’t change much, but it got faster and easier to manage. Our typical setup includes:
- Staging deployments triggered automatically on commit
- Manual production deployments for added control
- Build steps like
composer install,npm install, andnpm run prod - Post-deploy tasks like symlinking storage and setting permissions
- Restarting services like NGINX and OPcache
What Improved Most
The biggest changes we’ve noticed right away:
- Speed: Deployment times dropped significantly.
- UI: Faster, more modern, and easier to navigate.
- Clarity: Better logging made it easier to see exactly what’s happening at each step.
- Integration Support: The built-in Teams integration was a welcome addition.
Final Thoughts
“This could’ve been a heavy migration,” Alex admitted, “but the way DeployHQ handled it made it feel pretty effortless.”
A huge part of that success was thanks to Alex. His technical clarity, responsiveness, and collaborative spirit made the process extremely smooth. His deep understanding of Ponderosa’s deployment needs ensured that nothing got lost in translation and that every step was tailored for efficiency.
