Replacing the All-in-One DevOps Platform: ArgoCD, Vault, and a Best-of-Breed Stack

Introduction

Running a Proxmox homelab that hosts a growing collection of Docker containers and Node.js services has given me a front-row seat to exactly the kind of toolchain sprawl this post is about. There is a constant temptation to reach for the platform that promises to handle everything — CI/CD, monitoring, secrets, orchestration — in one tidy dashboard. For years, many engineering teams (and hobbyists scaling into something more serious) operate under this “Swiss Army Knife” philosophy, investing heavily in a massive, monolithic DevOps suite under the belief that integration friction is the ultimate enemy of velocity.

But as infrastructure moves from simple virtual machines to a complex microservices architecture, that all-in-one tool often becomes a bottleneck rather than an accelerator. The transition to a “Best-of-Breed” ecosystem is not just a technical shift — it is a change in how you think about your toolchain entirely. True DevOps maturity is not about how many features your primary tool has, but how well your specialized tools communicate with each other. In this post, I want to share a concrete journey of deconstructing a monolithic toolchain, the specific tools that improved deployment frequency, and the hard-earned lessons gathered while navigating the operational realities that follow an initial migration.

The Breaking Point: When “Integrated” Means “Inflexible”

The breaking point often arrives on a Friday afternoon deployment. A well-known legacy CI/CD platform that also doubles as an issue tracker and documentation hub sounds appealing until you actually need to extend it. Because the tool tries to do everything, the UI becomes cluttered, the API sluggish, and — most critically — integrating something like GitHub Actions for a new frontend microservice becomes nearly impossible without breaking an existing pipeline. Teams get stuck in a sunk-cost fallacy, fearing that moving away from the central hub will lead to fragmented data and siloed engineers.

The right move is to run a controlled experiment. Take one high-priority project and move it entirely out of the monolith. Focus on three specific areas: speed of feedback, ease of configuration, and developer autonomy. Here is what tends to emerge when you prioritize specialized tools over generalist platforms:

• Granular Control: Moving to Terraform for Infrastructure as Code means you stop fighting a GUI-based cloud manager and start treating your infrastructure exactly like application code — with diffs, pull requests, and code review.
• Reduced Latency: Build times can drop significantly simply by switching to a dedicated CI runner that does not carry the overhead of an entire project management suite. In practice, teams report reductions of 30–50% in pipeline execution time.
• Better Observability: Replacing the basic charts bundled in an all-in-one tool with Prometheus and Grafana reveals metrics about your Kubernetes clusters — request latency histograms, pod restart rates, memory pressure — that the bundled dashboards simply never exposed.

The New Stack: A Deep Dive into Our Specialized Toolset

Once you break the chains of the monolith, the goal is to select a “Best-of-Breed” stack that solves specific pain points in the software delivery lifecycle rather than chasing whatever tool is trending. Here is a breakdown of the components that tend to have the highest impact.

1. ArgoCD for GitOps Excellence

In a push-based CI/CD model, if the CI server loses its connection to the production cluster, you are flying blind. ArgoCD solves this by inverting the model entirely. Your Git repository becomes the single source of truth, and ArgoCD constantly reconciles the live state of your Kubernetes clusters against what is declared in Git. If someone manually changes a resource in the cluster, ArgoCD detects the drift and can automatically revert it.

The security benefit is equally significant: you no longer need to store production cluster credentials inside your CI environment. The cluster pulls its own desired state rather than being pushed to by an external system holding sensitive keys.

Here is a minimal ArgoCD Application manifest that wires a Git repository to a Kubernetes namespace — the kind of file I version-control alongside the application code itself:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-node-api
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/cristobal/my-node-api.git
    targetRevision: main
    path: k8s/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

The selfHeal: true flag is what makes this genuinely useful in production. Any manual change to the cluster — whether accidental or deliberate — gets corrected on the next sync cycle without anyone having to remember to re-run a pipeline.

2. HashiCorp Vault for Secrets Management

One of the most dangerous patterns in a monolithic CI/CD tool is secret sprawl — API keys and database passwords hardcoded into pipeline variables, accessible to anyone with sufficient permissions on the project. Vault centralises secrets and, more importantly, enables dynamic secrets: instead of a static database password, Vault instructs the database to generate a temporary credential with a short TTL that expires automatically after the job completes.

In a Node.js context, fetching a dynamic secret at application startup rather than baking it into an environment variable at build time looks roughly like this:

import Vault from 'node-vault';

const vault = Vault({
  apiVersion: 'v1',
  endpoint: process.env.VAULT_ADDR,
  token: process.env.VAULT_TOKEN,
});

async function getDbCredentials(): Promise<{ username: string; password: string }> {
  const secret = await vault.read('database/creds/my-node-api-role');
  return {
    username: secret.data.username,
    password: secret.data.password,
  };
}

// Called once at startup; credentials are rotated on next container restart
export const dbCredentials = await getDbCredentials();

The reason this matters operationally is that even if a container’s environment is somehow exposed, the credentials it holds are short-lived. The blast radius of a compromise is contained by design rather than by policy.

3. Pulumi for Modern IaC

Terraform is solid and battle-tested, but writing HCL can feel like a context-switch barrier for developers whose daily language is TypeScript, Python, or Go. Pulumi removes that barrier by letting you define infrastructure using the same languages your team already uses for application code — complete with the type safety, IDE autocompletion, and unit testing frameworks you already trust.

For a team building primarily in TypeScript and Node.js, this means a developer can open a Pulumi stack, read the infrastructure definition, and contribute a change without learning a domain-specific language first. That is a meaningful reduction in the wall between development and operations.

Practical Lessons: How to Transition Without the Chaos

Moving to a distributed toolchain can be daunting, and the biggest risk is attempting to do it all at once. These are the three strategies most likely to produce a stable migration without disrupting ongoing delivery cycles.

1. Apply the “Strangler Fig” pattern to your toolchain: Replace only one component at a time. Start with CI, leave the old tool managing issue tracking, and stabilise before touching CD or monitoring. A complete overnight cutover is where migrations fail.
2. Standardise the glue between tools: In a multi-tool ecosystem, the APIs and webhooks connecting your systems become as important as the tools themselves. A small internal library — even a single Node.js module using Express as a webhook relay — that standardises how tools emit events to Slack or write structured logs to a central aggregator pays dividends immediately.
3. Prioritise developer experience from day one: A tool with a 20% adoption rate delivers 20% of its theoretical value. Invest time in showing developers concretely how the new toolchain makes their day easier — specifically that they can debug their own pipelines without filing an Ops ticket. Practical demonstrations outperform documentation every time.

Conclusion

The journey from a monolithic “Swiss Army Knife” to a surgical, specialized toolchain is ultimately about accepting that no single vendor will ever understand your specific delivery constraints better than you do. By treating each layer of the stack — infrastructure provisioning, secret management, continuous delivery, observability — as a separate concern deserving a purpose-built tool, you end up with a system that is more robust, more auditable, and genuinely more enjoyable to operate.

If you find yourself fighting your tools more than using them, that friction is data. Start with one bottleneck, run a bounded experiment, and let the results guide the next step.