Bitbucket + Elestio: Auto-Deploy Your Repo on Every Push

If your team lives in Bitbucket, you know how deployment usually goes. Someone writes a bitbucket-pipelines.yml that builds the app, then SSHes into a server and runs a deploy script that only one person fully understands. It works until that person goes on vacation, the SSH key gets rotated, or the server needs a security patch nobody scheduled.

Until now, Elestio's CI/CD could build and deploy straight from GitHub and GitLab, and Bitbucket users had to mirror their repos or move them. That changed this week: Bitbucket is now a first-class source in Elestio CI/CD. You connect your Bitbucket account, pick a repository and a branch, and every push to that branch redeploys your app on a VM that's yours alone. This guide walks through the setup, what happens under the hood, and the few things that trip people up.

What You Get

Elestio CI/CD builds your code on every push, the way Heroku, Render or Railway do. The difference is where it runs: on a dedicated VM in your Elestio project, not on a shared cluster. That VM can also host any of Elestio's 400+ managed open-source services, so your app, its PostgreSQL database, a Redis cache and a Keycloak login server can all live in the same project, managed the same way.

With Bitbucket support, the deployment sources are now:

Prerequisites

• An Elestio account
• A Bitbucket Cloud repository (bitbucket.org) with an app you can build and run: Node.js, Python, PHP, Go, Ruby, a static site, a Dockerfile or a Docker Compose project
• The port your app listens on

Step 1: Connect Bitbucket

In the Elestio dashboard, open CI/CD in the left sidebar and pick Bitbucket as the deployment source. A Bitbucket window opens and asks you to authorize Elestio.

The permissions list looks long, so here's what each part is for. Elestio asks for read access to your account and workspaces (to list your repositories), write and admin rights on repositories, and permission to manage webhooks. The webhook is the important one: Elestio registers it on the repo you choose, and that's what turns a git push into a deployment. Write access is used when you import a third-party repository into your account (see below).

One thing to check before you start: Bitbucket only lets repository admins manage webhooks, so you need admin rights on the repo you want to deploy. A regular write role isn't enough.

Step 2: Pick the Repository and Branch

Once connected, choose the workspace, then the repository, then the branch you want to deploy, usually main or production. Each pipeline follows exactly one branch, so a common setup is two pipelines on the same repo: main to production and develop to a staging VM.

Step 3: Choose Where It Runs

You have two options:

• Deploy on a new VM. Pick a cloud provider, region and size. Elestio creates a CI/CD target, which is the VM your pipelines run on.
• Deploy on an existing VM. Reuse a CI/CD target you already have. One target can host several pipelines, which is handy for small apps and staging environments.

For a typical Node.js or Python app, a 2 vCPU / 4 GB VM (about $16/month on Netcup) is a comfortable start, and it leaves room to build Docker images without running out of memory. You pay for the VM, and the builds run on it, so there's no separate build-minute meter to watch.

Step 4: Tell Elestio How to Build and Run It

This is where most failed deployments come from, so take a minute here. You'll set:

• Runtime and version: for example Node.js 20, Python, PHP, or Docker Compose if your repo has a docker-compose.yml at the root
• Framework and root directory: useful in monorepos, where the app lives in a subfolder
• Install, build and run commands: for a Node app, typically npm ci, npm run build and npm start
• Port mapping: the public HTTPS port 443 forwards to the port your app listens on, on the host

For a Docker Compose project, the port mapping points at the host port published in your compose file, not the container's internal port. If your compose file says "3000:8080", Elestio forwards to 3000.

Optional lifecycle scripts let you run commands before and after the build, such as database migrations. Leave them empty if you don't need them.

Click Create and Elestio clones the repo, builds it and puts it behind its managed Nginx reverse proxy with a free TLS certificate on an Elestio subdomain. You can add your own domain later.

Step 5: Push and Watch It Deploy

Make a commit, push it to the branch, and open the pipeline in Elestio. The webhook kicks off a new build, and you can follow its build and runtime logs live.

If you ever need to freeze deployments (during an incident, or while you push a series of commits), turn off Webhook Trigger in the pipeline settings. Pushes are then ignored until you turn it back on, and you can still deploy by hand. The Elestio docs cover that toggle in detail.

Bonus: Deploy Someone Else's Public Repo

The Import a Third-Party Git Repository option takes any public GitHub, GitLab or Bitbucket URL, creates a copy in your own account (private if you tick the box), and deploys it. It's a fast way to try an example app or a starter template without forking it by hand. The step-by-step guide has screenshots of each screen.

Add the Rest of Your Stack

Most apps need more than their own code. In the same Elestio project you can deploy a managed PostgreSQL, Redis or Keycloak and pass their connection details to your pipeline as environment variables. Each service gets automated backups, updates and monitoring, so the parts of your stack you didn't write are handled for you.

Troubleshooting

My repository doesn't appear in the list, or the pipeline fails to set up. Check that you picked the right workspace and that your Bitbucket user is an admin on that repository. Ask a workspace admin to grant it, then reconnect.

The pipeline is created but never builds. The runtime doesn't match the repo. A repo with only a docker-compose.yml needs the Docker Compose runtime, not Node.js.

The build succeeds but the site shows a 502. The port mapping points at the wrong port, or your app only listens on localhost. Bind to 0.0.0.0 and check the port against your run command or compose file.

Pushes don't trigger a deployment. Confirm you pushed to the branch the pipeline follows, and that Webhook Trigger is enabled. If you removed the webhook in Bitbucket's repository settings, reconnect the pipeline so Elestio can register it again.

I'm on Bitbucket Data Center. The integration connects to Bitbucket Cloud (bitbucket.org). For a self-managed Bitbucket server, the Docker Compose source or a mirror to a supported provider is the way to go for now.

That's it: connect, pick a branch, describe the build, push. Ready to try it? Open Elestio CI/CD and point it at your Bitbucket repo.

Thanks for reading ❤️ See you in the next one 👋