Engineering platform

One delivery pipeline, from commit to production.

The projects in our case studies share the same practices. They do not depend on the language: Java, TypeScript and Python go through the same checks and the same deployment model.

A hybrid infrastructure, run in production

Client applications and AI inference run on our own Kubernetes cluster. Dedicated APIs run on a separate server. For clients who already use a public cloud, integration is done with Terraform.

TDKSOFT infrastructure architectureVisitors reach, over HTTPS, the NGINX Ingress of a Kubernetes cluster at 1blu, which serves the web applications, PostgreSQL (CloudNativePG), self-hosted LLM inference, Argo CD and monitoring. The applications call, over HTTPS, APIs hosted on a Hetzner VPS. Code goes from GitHub through CI and the image registry, then Argo CD syncs the cluster. Integrations on AWS, GCP or Azure are provisioned with Terraform depending on the client.VisitorsHTTPSKubernetes cluster — 1bluClient applicationsIngress NGINXTLS · cert-managerWeb applicationsclient sites and back officesPostgreSQLCloudNativePGArgo CDGitOps, sync after reviewMonitoringPrometheus · Grafana · LokiEncrypted secretsSOPS · Kubernetes SecretsSelf-hosted LLMllama.cpp · quotaskubeadm · 2 nodes · CalicoVPS — HetznerAPI servicesAPI servicesconsumed by the applicationsClient cloudPer engagementAWSGCPAzureTerraformInfrastructure-as-Code integrationsGitHubPR and reviewCI and gatesJenkins · GitHub ActionsRegistrySemVer-versioned imagesDelivery pipelineHTTPS: APIssyncimages
Simplified view: no address or host name is published.
  • Kubernetes cluster at 1blu: installed with kubeadm, Calico networking, two nodes; it hosts the clients' sites and applications.
  • Self-hosted LLM inside the cluster: llama.cpp behind a gateway with per-client quotas, used by the sites' conversational assistants.
  • Separate Hetzner VPS: API services consumed by the cluster's applications.
  • Clients' public clouds (AWS, GCP, Azure): integrations provisioned with Terraform, according to each client's existing environment.
  • Git-driven production: Argo CD syncs the cluster, no manual deployment commands.
Delivery pipeline : Commit and PR → CI and gates → Versioned image → GitOps promotion → Argo CD → ProductionCommit and PRCI and gatesVersioned imageGitOps promotionArgo CDProduction
Delivery pipeline

Continuous integration with gates

A PR only reaches the main branch after passing the checks.

  • Lint, typecheck, tests and build on every PR (Jenkins or GitHub Actions depending on the project).
  • Secret scanning, dependency analysis and static analysis; SBOM and image scanning on the most demanding projects.
  • API contracts (OpenAPI, HTTP contracts) checked in CI to prevent silent breaking changes.

Containers and Helm

Every application ships as a container image and is described by a versioned Helm chart or Kustomize manifests.

  • Multi-stage Docker builds, images published per release.
  • A generic Helm chart fed by a profile per application, rendered and validated before any commit.

GitOps with Argo CD

Production is whatever Git says. No manual deployment to production.

  • Promoting a release is a reviewed change in a GitOps repository.
  • Argo CD diffs, then syncs after the diff is reviewed.
  • Direct deployment commands are blocked in the tooling.

SemVer versioning

Git tag, container images, chart version and application version stay aligned.

  • A CI check verifies version alignment.
  • Published tags are never moved or deleted.

Secret management

No plain-text secret in Git or in logs.

  • Secrets encrypted with SOPS and age in infrastructure repositories.
  • Any accidental exposure of a secret means rotating it, no exceptions.

AI-assisted engineering governance

Coding agents work inside a written framework that is reviewed like code.

  • Engineering contracts (AGENTS.md) reused across repositories.
  • Architecture decision records and phased delivery with human approval at each gate.
  • A verified hand-off state at the end of every session, so each restart begins from facts, not assumptions.
See these practices in the case studies →