diff --git a/.gitignore b/.gitignore
index cc29f1fd..ac2435b4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -115,3 +115,7 @@ output/
 
 #osx
 .DS_Store
+
+# Terraform
+.terraform
+.terraform.lock.hcl
\ No newline at end of file
diff --git a/GIT-WORKFLOW.md b/GIT-WORKFLOW.md
deleted file mode 100644
index 31cb9c3c..00000000
--- a/GIT-WORKFLOW.md
+++ /dev/null
@@ -1,70 +0,0 @@
-[Git Flow]: https://nvie.com/posts/a-successful-git-branching-model/
-[Semantic Versioning]: https://semver.org
-
-> [!IMPORTANT]
-In the following, **MAJOR**, **MINOR** and **PATCH** refer to [Semantic Versioning].
-
-We use [Git Flow] as our branching strategy, which is well suited for projects with long release cycles.
-We add also support for maintanance of previous **MAJOR** versions.
-Here we present a summary of the strategy.
-
-## **Main branches**:
-
-* **master**: reflects the code in production for the current **MAJOR**.
-* **develop**: integrates code for the next release.
-* **support/x.y**: reflects code in production for previous **MAJOR**,
-allowing for **PATCH** increments. 
-
-## **Feature branches**:
-
-1. Create a branch from **develop**.
-2. Work on the feature.
-3. Rebase on-top of **develop**.
-3. Merge back to **develop** with a merge commit.
-
-There is currently no convention about the name of the feature branches,
-other than being descriptive and separate the words using hyphens "-".
-
-To maintain a clear semi-linear history in **develop**,
-we rebease on top of **develop** before merging the branch.
-The merge should be done **forcing a merge commit**,
-otherwise would be a fast-forward merge (because we rebased)
-and the history would be linear instead of semi-linear,
-losing the context of the branch.
-This is enforced in the GitHub UI,
-but locally is done with:
-```shell
-git merge branch --no-ff
-```
-
-## **Release branches**:
-
-1. Create a branch named **release/x.y.z** from **develop**.
-2. Perform all steps needed to make the release.
-3. Merge to **master** and **develop**.
-4. Tag **master**.
-
-If the release its a **MAJOR** release, create a branch **support/x.y**,
-where "x" is the previous **MAJOR** and "y" its last **MINOR** release.
-
-## **Hotfix branches**:
-
-These are quick **PATCH** increments done only to current **MAJOR** release:
-
-1. Create a branch named **hotfix/x.y.z** from **master**.
-2. Work on the fix. Perform steps needed to make the release.
-3. Merge back to **master** and also to **develop**.
-4. Tag **master**.
-
-## **Patch branches**:
-
-These are **PATCH** increments to previous **MAJOR** releases:
-
-1. Create a branch named **patch/my-patch** from **support/x.y**.
-2. Work on the fix. Perform steps needed to make a release.
-3. Merge to **support/x.y**.
-4. Tag **support/x.y**. 
-
-If you need also this fix in the current **MAJOR**,
-you will have to re-work the fix to be compatible with the new API.
-You can work it in a [feature branch](#feature-branches) or make a [hotfix](#hotfix-branches).
\ No newline at end of file
diff --git a/GITHUB-FLOW.md b/GITHUB-FLOW.md
new file mode 100644
index 00000000..111b8559
--- /dev/null
+++ b/GITHUB-FLOW.md
@@ -0,0 +1,67 @@
+# GitHub Flow
+
+[GitHub Flow]: https://githubflow.github.io/
+
+<div align="justify">
+
+[GitHub Flow] is an ideal workflow for teams that deploy frequently
+and want to iterate quickly without the overhead of long release cycles or complex branching strategies.
+It keeps the process simple and fast,
+enabling continuous integration and deployment,
+which helps catch issues early and deliver features to users rapidly.
+
+These are the basic rules of the workflow:
+1. **`main` is always deployable**
+
+  The `main` branch must be stable and ready to deploy at all times. Never push untested or broken code.
+
+2. **Create descriptively named branches from `main`**
+
+  Start every new feature, fix, or idea in a new branch based on `main`, with clear and meaningful names.
+
+3. **Push to your branch often**
+
+  Push work regularly to the remote to back it up, share progress, and trigger CI.
+
+4. **Open a Pull Request early**
+
+  Use pull requests for code review, discussion, or help—long before the branch is “done.”
+
+5. **Get reviewed and approved before merging**
+
+  Don’t merge until someone reviews and approves your work (even with just a 👍 or `:shipit:`).
+
+6. **Deploy right after merging to `main`**
+
+  Once merged, deploy immediately or soon—everything in `main` should be safe and shippable.
+
+---
+
+This flow emphasizes **simplicity, speed, and collaboration**, especially for teams that deploy frequently.
+
+### Additional team conventions
+
+- If you plan to make a release immediately after merging,
+  bump the version directly in your feature branch.
+  This avoids the need to create a separate release branch just for the version bump.
+
+- Always rebase feature branches on top of `main` before merging them.
+  This, combined with enforcing **merge commits** in GitHub repository settings,
+  results in a semi-linear history on the `main` branch,
+  which is very helpful when using `git log`.[^1]
+  If **merge commits** are not enforced,
+  Git will perform a **fast-forward merge** after rebasing,
+  creating a linear history
+  and losing the context of the feature branch.
+  If merging locally, avoid fast-forward merges with:
+  ```shell
+  git checkout main
+  git pull
+  git merge branch_name --no-ff
+  ```
+
+[^1]: When performing a rebase, it's acceptable to `push --force` to your own feature branch,
+      but **never** on shared branches.
+      Protect `main` and/or `develop` from force pushes via GitHub settings.  
+
+</div>
diff --git a/README.md b/README.md
index 76d82dfa..17a26155 100644
--- a/README.md
+++ b/README.md
@@ -23,7 +23,7 @@ which are broadcasting using the same MMSI at the same time.
 [docker compose plugin]: https://docs.docker.com/compose/install/linux/
 [examples]: examples/
 [git installed]: https://git-scm.com/downloads
-[git workflow documentation]: GIT-WORKFLOW.md
+[git workflow documentation]: GITHUB-FLOW.md
 [Makefile]: Makefile
 [pip-tools]: https://pip-tools.readthedocs.io/en/stable/
 [requirements.txt]: requirements.txt
diff --git a/cloudbuild.yaml b/cloudbuild.yaml
deleted file mode 100644
index 0b82c13d..00000000
--- a/cloudbuild.yaml
+++ /dev/null
@@ -1,38 +0,0 @@
-steps:
-- name: 'gcr.io/cloud-builders/docker'
-  args: [
-    'build',
-    '-t', '${_IMAGE_NAME}:test',
-    '-f', 'Dockerfile',
-    '--target', 'dev',
-    '.',
-  ]
-
-- name: 'gcr.io/cloud-builders/docker'
-  args: [
-    'run',
-    '--rm',
-    '--entrypoint', 'py.test',
-    '${_IMAGE_NAME}:test',
-  ]
-
-- name: 'gcr.io/cloud-builders/docker'
-  args: [
-    'build',
-    '-t', '${_IMAGE_NAME}:${TAG_NAME}',
-    '-t', '${_IMAGE_NAME}:latest',
-    '-f', 'Dockerfile',
-    '--target', 'prod',
-    '.',
-  ]
-
-images:
-  - '${_IMAGE_NAME}:${TAG_NAME}'
-  - '${_IMAGE_NAME}:latest'
-
-timeout: 600s
-substitutions:
-  _IMAGE_NAME: 'gcr.io/${PROJECT_ID}/github.com/globalfishingwatch/pipe-segment'
-options:
-  dynamic_substitutions: true
-
diff --git a/cloudbuild/backend.tf b/cloudbuild/backend.tf
new file mode 100644
index 00000000..d89cbd9a
--- /dev/null
+++ b/cloudbuild/backend.tf
@@ -0,0 +1,6 @@
+terraform {
+  backend "gcs" {
+    bucket = "gfw-int-infrastructure-tfstate-us-central1"
+    prefix = "cloudbuild-pipe-segment"
+  }
+}
\ No newline at end of file
diff --git a/cloudbuild/main.tf b/cloudbuild/main.tf
new file mode 100644
index 00000000..a8d7585f
--- /dev/null
+++ b/cloudbuild/main.tf
@@ -0,0 +1,17 @@
+module "trigger_push_to_tag" {
+  source              = "git::https://github.com/GlobalFishingWatch/gfw-terraform-modules.git//modules/cloudbuild-trigger?ref=v0.2.0"
+  registry_artifact   = "core"
+  repo_name           = "pipe-segment"
+  tag                 = ".*"
+  trigger_description = "Builds and publishes a Docker image on every tag push." 
+}
+
+module "trigger_push_to_main" {
+  source              = "git::https://github.com/GlobalFishingWatch/gfw-terraform-modules.git//modules/cloudbuild-trigger?ref=v0.2.0"
+  registry_artifact   = "core"
+  repo_name           = "pipe-segment"
+  branch              = "main"
+  trigger_description = "Builds and publishes a Docker image on every push to the main branch."
+}
+
+
diff --git a/pipe_segment/version.py b/pipe_segment/version.py
index 3d96b276..6a92b244 100644
--- a/pipe_segment/version.py
+++ b/pipe_segment/version.py
@@ -1 +1 @@
-__version__ = '5.0.1'
+__version__ = '5.0.2'