PostgreSQL: 5. GitLab CI
This documentation is part of the GitHub Actions & GitLab CI guide. You can view the complete guide here: Launch a real PostgreSQL service from your GitHub Actions or GitLab CI pipeline, run your tests against it, and automatically tear it down.
👋 Welcome to the Stackhero documentation!
Stackhero offers a fully managed PostgreSQL cloud solution, designed for reliability and performance:
- Unlimited connections and data transfers for effortless scalability.
- PgAdmin web interface included for easy database management.
- Popular extensions included, such as
PostGIS,TimescaleDB, andPgVector.- Simple, one-click updates to keep your database secure and up to date.
- High performance and enhanced security on private, dedicated infrastructure.
Save time and make your life easier: it only takes 5 minutes to try Stackhero's PostgreSQL cloud hosting solution!
You can save this configuration as .gitlab-ci.yml. With this setup, each pipeline run spins up a fresh real PostgreSQL for your tests.
test:
image: ubuntu:24.04
variables:
STACK_NAME: "ci-postgresql-$CI_PIPELINE_ID-$CI_JOB_ID"
INSTANCE: "10G" # Change this as needed (see step 3)
REGION: "europe"
SERVICE_STORE: "postgresql"
# STACKHERO_TOKEN comes from the CI/CD variable you created in step 1.
script:
- set -euo pipefail
- curl -fsSL https://www.stackhero.io/install.sh | sh
- apt-get update && apt-get install -y --no-install-recommends jq curl postgresql-client
- STACK_ID=$(stackhero --format=script stack-create --name="$STACK_NAME")
- echo "STACK_ID=$STACK_ID" >> deploy.env
- SERVICE_ID=$(stackhero --format=script service-add --stack="$STACK_ID" --service-store="$SERVICE_STORE" --instance="$INSTANCE" --region="$REGION")
- echo "SERVICE_ID=$SERVICE_ID" >> deploy.env
- stackhero service-wait-for --service="$SERVICE_ID"
- config=$(stackhero service-configuration-get --service="$SERVICE_ID" --format=json)
- host=$(echo "$config" | jq -r '.configuration.domain')
password=$(echo "$config" | jq -r '.configuration.password')
# Run a trivial query against the database.
- PGPASSWORD="$password" psql "host=$host port=5432 user=admin dbname=admin sslmode=require" -c "SELECT 1;"
- echo "✅ PostgreSQL is reachable from CI."
# You can run your own test suite here using the credentials above ...
after_script:
- test -f deploy.env && . ./deploy.env || true
- >
if [ -n "${SERVICE_ID:-}" ]; then
stackhero service-delete --service="$SERVICE_ID" --confirm
stackhero service-wait-for --service="$SERVICE_ID"
fi
- >
if [ -n "${STACK_ID:-}" ]; then
stackhero stack-delete --stack="$STACK_ID" --confirm
fi
On GitLab, cleanup is handled in after_script. This section is always executed, even if the job fails, ensuring your PostgreSQL resources are deleted and you are not billed for unused resources.
In GitLab,
after_scriptruns in a fresh shell. To handle this, the script writes the service and stack IDs todeploy.envduring the job and reloads them before cleanup. This ensures that even if something fails mid-job, your resources are still deleted.
That is the complete CI lifecycle for PostgreSQL: create a stack, add the service, wait, retrieve credentials, smoke-test, and always tear down. Each pipeline run gets a real, isolated service, with nothing left running when you are done. For more information about available commands and non-interactive STACKHERO_TOKEN authentication, you can refer to the full CLI documentation.