How Greenstand Runs Treetracker on DigitalOcean

Running a system that syncs millions of geo-referenced photos, processes field data from remote regions, and powers public dashboards requires reliable infrastructure. This article gives a behind-the-scenes look at how Greenstand deploys Treetracker on DigitalOcean Kubernetes (DOKS).

High-level architecture: Treetracker services running on a DigitalOcean Kubernetes cluster, connected to managed PostgreSQL and object storage.

Logging into DigitalOcean

The DigitalOcean control panel is the central place where the Greenstand team manages Kubernetes clusters, databases, networking and access. Team members authenticate via the web UI or through the doctl command-line tool.

For local access, engineers use doctl to connect the Kubernetes cluster to their machine:

# Authenticate doctl (once)
doctl auth init

# List available clusters
doctl kubernetes cluster list

# Save kubeconfig for the treetracker cluster
doctl kubernetes cluster kubeconfig save treetracker-cluster

# Verify access
kubectl get nodes

Creating the Kubernetes Cluster

Treetracker is composed of multiple microservices (mostly Node.js and Python), a web frontend, and PostgreSQL databases. All stateless services run inside a DigitalOcean Kubernetes (DOKS) cluster, which gives Greenstand automatic node management, load balancing, and integration with other DigitalOcean products.

Creating a DigitalOcean Kubernetes cluster with node pool and region selection.

The typical setup for the Treetracker cluster includes:

• A region close to target users (for example, FRA1 or SFO3).
• One or more node pools, often CPU-optimized droplets.
• Cluster auto-upgrades for minor Kubernetes versions.
• Autoscaling enabled on the main worker node pool.

Once the cluster is provisioned, DigitalOcean exposes the Kubernetes API and generates a kubeconfig, which is then used in CI/CD pipelines as well as by developers working locally.

Kubernetes cluster overview page with node pools and workloads.

Preparing the Deployment Environment

Inside the DigitalOcean Kubernetes cluster, Greenstand organizes Treetracker into multiple namespaces and integrates with other DigitalOcean services such as container registry and managed databases.

Namespaces

Typical namespaces include:

• treetracker-production
• treetracker-staging
• utility-services (for shared infra like queues and caches)

# Example: create a production namespace
kubectl create namespace treetracker-production

Container Registry (DOCR)

Application images are built from the Greenstand GitHub repositories and pushed to DigitalOcean Container Registry (DOCR). CI/CD pipelines (for example using GitHub Actions) handle:

• Building Docker images.
• Tagging images by branch or version.
• Pushing to DOCR.
• Triggering Kubernetes deployments.

Core repositories include (among others):

• treetracker-web-map
• treetracker-api
• treetracker-wallet-api
• more Greenstand repositories

Managed PostgreSQL and Core Services

For persistence, Treetracker uses DigitalOcean Managed PostgreSQL clusters. Using the managed database service reduces operational overhead and gives automatic backups, high availability, and built-in metrics.

Managed PostgreSQL cluster in DigitalOcean used by Treetracker services.

Database connection strings are stored as Kubernetes Secrets and mounted into the microservices as environment variables. For configuration management, tools like SOPS or sealed-secrets can be used to encrypt sensitive values in Git.

With infrastructure in place, the core Treetracker services are deployed:

• Treetracker API — main backend for tree and planter data.
• Wallet API — tracks tokens and payments.
• Image ingestion & processing pipelines.
• Web Map frontend for public visualization.
• Internal admin and verification tools.

# Example: install an API service via Helm
helm install treetracker-api ./charts/treetracker-api/ \
  --namespace treetracker-production

# Example: apply a web frontend deployment
kubectl apply -f deployments/web-map.yaml \
  --namespace treetracker-production

External access is managed through Kubernetes Service objects of type LoadBalancer, which automatically create DigitalOcean load balancers:

apiVersion: v1
kind: Service
metadata:
  name: treetracker-api
  namespace: treetracker-production
spec:
  type: LoadBalancer
  selector:
    app: treetracker-api
  ports:
    - port: 80
      targetPort: 8080

Monitoring, Scaling, and Reliability

Once the Treetracker platform is running, DigitalOcean provides metrics and insights that help keep the system healthy and responsive. The cluster metrics view offers node-level CPU and memory usage, pod restarts, and network traffic.

DigitalOcean Kubernetes metrics used to monitor Treetracker workloads.

Scaling is handled at multiple layers:

• Node pool autoscaling adds or removes droplets based on cluster utilization.
• Horizontal Pod Autoscalers adjust the number of pod replicas based on CPU or custom metrics.
• CronJobs and scheduled tasks handle nightly processing and data cleanup.

CI/CD pipelines connect GitHub to DigitalOcean: when a change is merged into the main branch of a Treetracker repository, a new container image is built, pushed to DOCR, and rolled out to the Kubernetes cluster with a rolling update strategy.

Why DigitalOcean Works for Greenstand

By running Treetracker on DigitalOcean Kubernetes, Greenstand gains a production-ready environment that is scalable, observable, and maintainable, while staying manageable for a small, globally distributed team.

DigitalOcean’s clean user interface allows the engineering team to spend more time on what matters most: building tools that support communities restoring degraded ecosystems, and making sure every verified tree in the Treetracker system is counted, visible, and valued.

To learn more about the project and the broader ecosystem of tools around it, visit the Greenstand documentation and explore the Greenstand GitHub organization .