In our first two posts we explored the "slow is smooth; smooth is fast" philosophy and how essesseff embodies it in practice. This post goes one level deeper: the concrete design decisions that make essesseff a DevOps Application Lifecycle Management (ALM) PaaS-as-SaaS — and why those choices matter for security, simplicity, scalability, and control.
essesseff is not a random set of features. It is the result of deliberate choices about where state lives, who owns what, and how to keep the platform from ever holding your Kubernetes config or secrets. Here we walk through the main architectural decisions and the reasoning behind them.
Build Once, Deploy Many
A single container image is built from your source repository (typically from the main branch). That same image — the same digest, the same tag — is then promoted through environments: DEV → QA → STAGING → PROD. essesseff never rebuilds per environment. It only updates which image tag each environment uses. This pattern is established by the essesseff app templates, and altering or removing it is strongly discouraged.
Why it matters: Rebuilding per environment would mean different binaries in QA vs PROD, undermining the “test what you ship” principle. Build-once-deploy-many gives you one artifact, one set of tests, and one path from build to production. Deployments become a matter of updating a pointer (the image tag) in Git, not rebuilding or repackaging.
Trunk-Based Development
essesseff assumes a single main branch. Feature work is done in short-lived branches and merged into main. The pipeline is triggered from main. There are no long-lived environment branches (no develop, staging, release branches) that you have to merge back and forth.
Why it matters: Trunk-based development reduces merge conflicts, keeps the deployment model simple, and aligns with GitOps: the state of each environment is “what image tag is in this repo for this environment,” not “which branch is deployed where.” Slower-feeling discipline on branching pays off in smooth, predictable promotions and fewer surprises.
Argo CD Deployed to the Same Cluster It Deploys To
Argo CD runs inside your Kubernetes cluster — the same cluster (or cluster per environment) that it is deploying applications to. essesseff does not run Argo CD for you; you install and operate Argo CD. The essesseff app templates, however, provide easy setup of Argo CD so you can get going quickly. essesseff only tells Git what image tag to use in your Helm config repos. Argo CD then pulls from GitHub and applies the change.
Why it matters: You keep full control of the cluster and of Argo CD. There is no “essesseff’s Argo CD” holding credentials to your clusters. You own the deployment controller and the cluster; essesseff stays in the role of updating Git so that your existing Argo CD does the deploy.
Image Tag Format: semver-githash-datetimestampUTC
Container images are tagged in a fixed format: semver-githash-datetimestampUTC, for example 1.0.0-a1b2c3d-20250930T120000Z. Semantic version, short Git commit hash, and build timestamp in UTC. The essesseff app templates establish this pattern, and altering or removing it is strongly discouraged.
Why it matters: Every image is uniquely identifiable and traceable to a commit and a point in time. No “latest,” no ambiguous tags. Promotions in essesseff are simply updating values.yaml to reference this tag; the same tag is used across environments so you always know exactly what is where.
Argo CD Pulls from GitHub — essesseff Pushes Only to Git
Argo CD is configured to watch your GitHub repositories (Helm config repos and Argo CD app-definition repos). When you promote in essesseff, the platform updates the appropriate config repo in GitHub — for example, setting the image tag in config-qa/values.yaml. Argo CD sees the Git change and syncs. essesseff does not push manifests into the cluster, and it does not hold a copy of your Kubernetes or Argo CD configuration.
Why it matters: This is the key to not storing K8s or Argo CD config or secrets in essesseff. The source of truth for “what is deployed” is Git. essesseff only mutates Git (via the GitHub App) with image tag updates. Your cluster credentials, Kubeconfig, and Argo CD secrets stay with you. The platform never needs to store or see them, which reduces blast radius and keeps compliance and security boundaries clear.
Division of Repos: Source, Helm Config, Argo CD
Each essesseff app is made of 9 repositories:
- One source repo — application code; single
mainbranch; builds produce the container image. - Four Helm config repos — one per environment:
config-dev,config-qa,config-staging,config-prod. Each holds Helm values (and related config) for that environment. essesseff updatesimage.tag(and related fields) in these repos when you promote. - Four Argo CD repos — one per environment:
argocd-dev,argocd-qa,argocd-staging,argocd-prod. Each holds the Argo CD Application definitions that point at the corresponding Helm config repo and the cluster. Argo CD in your cluster watches these repos.
essesseff syncs RBAC between essesseff roles and the corresponding GitHub teams: everyone on the team has read access to all of these repos, but only the appropriate role(s) have write access to a given repo (e.g. Developers to source and config-dev, QA to config-qa, Release Engineers to config-staging and config-prod). The DevOps Engineer role — like the admin/owner role — has broad read/write access to all repos. That keeps Git permissions aligned with who is allowed to promote what in the platform.
Why it matters: Clear separation of concerns. Source is “what we build.” Config repos are “what we deploy (image tag + env-specific values).” Argo CD repos are “where and how we deploy.” Environment-specific repos make promotions a clean, auditable Git commit to the right repo and avoid overloading a single repo with every environment. It might look like more repos up front, but it makes promotions and rollbacks straightforward and keeps each repo’s purpose obvious.
Event-Driven Promotions and RBAC
Promotions are driven by explicit events in the essesseff UI (or API): Developer declares Release Candidate, QA accepts or rejects, QA declares Stable, Release Engineer deploys to STAGING or PROD. Each action is tied to a role and an identity. essesseff then updates the corresponding config repo in GitHub; Argo CD does the rest.
Why it matters: You get a clear audit trail (who promoted what, when) and enforcement of who can do what, without essesseff ever needing to hold cluster access. RBAC is enforced in the platform and, where applicable, reflected to GitHub (e.g., team membership) so that Git access and deployment actions stay aligned.
No Central Storage of K8s or Argo CD Secrets
essesseff does not store your Kubernetes credentials, Argo CD credentials, or cluster endpoints. It does not inject deployment credentials into your cluster. The platform only needs permission to update your GitHub repos (via the GitHub App). Argo CD and the cluster stay entirely in your control.
Why it matters: Fewer secrets in the platform means a smaller attack surface and simpler compliance. You can rotate cluster and Argo CD credentials without touching essesseff. The “pull from Git” model is what makes this possible.
Deterministic, No Unpredictable AI in the Pipeline
essesseff’s promotion and deployment behavior is deterministic. There are no opaque “AI” steps that decide what gets deployed or when. What you see in the UI and in Git is what gets deployed. Builds are triggered by Git events; promotions are triggered by explicit user (or API) actions.
Why it matters: Predictability and auditability. You can reason about and explain every promotion. There are no hidden model outputs or non-deterministic steps in the path from “Accept RC” to “image tag in config-qa and deployed by Argo CD.”
Full Audit Trail and Visibility
essesseff stores and displays build events, image lifecycle states, and deployment events (including when Argo CD reports success or failure). You get a single pane of glass for “what was built, who promoted it, and what is deployed where,” with links through to GitHub — including Git repo push events that trigger Argo CD deployments — but essesseff does not link directly to Argo CD itself.
Why it matters: “Slow is smooth; smooth is fast” only works if you can see what’s happening. The audit trail and dashboards (including DORA-oriented metrics and the Image Lifecycle Journey) are there so that the discipline of the process is visible and improvable.
Tying It Back to “Slow Is Smooth; Smooth Is Fast”
These design decisions are of a piece with the philosophy in the first two posts. Trunk-based development and a single main branch feel “slower” than juggling many branches, but they make promotions smooth. Putting all deployment state in Git and having Argo CD pull (instead of essesseff pushing to the cluster) feels like more setup, but it keeps the platform simple and your secrets out of our hands. The 9-repo split and the image tag format add structure up front so that every promotion is a clear, traceable step.
Together, these choices are what make essesseff a DevOps ALM PaaS-as-SaaS: a platform that orchestrates where your application goes (by updating Git) without ever taking ownership of how it gets there (that’s your Argo CD and your cluster). You stay in control; we help you move deliberately and then move fast. They also support scalability: because essesseff does not run or store your deployment runtime, you can add more apps, teams, and environments without the platform becoming a bottleneck or a single point of failure.
Previous: How essesseff Embodies 'Slow Is Smooth; Smooth Is Fast' in DevOps