Application delivery deep dive

Bundles are Loopback’s answer to a fragmented reality: one team runs CI in Jenkins, another hand-rolls Helm values, another maintains Argo CD Applications, and nobody can answer “what commit is in prod?” without opening five tools.

This page goes beyond the overview in Bundles overview. It is written for VP Engineering, platform leads, and solutions architects who want to map Loopback to existing toolchain categories—without pretending Loopback is a drop-in replacement for every niche feature on day one.

Deployment note: automation in your tenant must be enabled by your operator (Git connectivity, build runners, registry, GitOps controller hooks). If any prerequisite is missing, use this document for planning, not promises.

Part 1 — What bundles replace (conceptually)

1.1 Build pipelines (CI)

Traditional: a pipeline clones Git, builds an image, pushes to a registry, then triggers deploy.

Bundle-oriented: Loopback tracks revisions tied to Git state and runs build operations as first-class product workflows. You still get container images, but the system of record moves into Loopback:

Which commit built?
Which Dockerfile / context?
Which registry tag / digest?
Who triggered it and which RBAC gate allowed it?

User translation: Bundles centralize build orchestration and evidence even if the underlying driver is Tekton, Buildkit, Kaniko, or another engine your operator selects.

1.2 Helm chart assembly

Teams waste time on:

“Where does the chart live?”
“Which values file is canonical for staging?”
“Who applied the hotfix to prod values?”

Bundle environments carry manifest material appropriate to that track (dev/stage/prod). Discovery can find charts inside the same repo as code or reference external chart sources, depending on how you configure the environment.

Patterns Loopback supports in principle:

Monorepo: application code + Helm chart in one Git repository (common for small services).
Chart-only repo: Git holds charts; image build still comes from an app repo (often via separate bundle or operator process).
External Helm repository: chart lives in a Helm repo / OCI chart registry; Loopback’s deploy path still needs a revision that points to the right image + chart version combination.

1.3 Deployment systems (Argo CD, Flux, “GitOps engines”)

Loopback’s deploy automation is GitOps-aligned: it drives continuous reconciliation from registry-backed sources rather than a one-off kubectl apply.

In the shipped automation story, Flux primitives are used on the operator-managed parent cluster to reconcile into workspace namespaces. Practically:

You get declarative drift correction for bundle-driven workloads.
You still interact through Loopback for promotion, RBAC, and audit, not only through raw Git commits.

Important nuance: Loopback is not “Argo CD inside Loopback UI.” It is a productized path with opinionated integration. If you require Argo-specific features, discuss coexistence with your operator.

Part 2 — End-to-end lifecycle (detailed)

Stage A — Connect Git safely

OAuth to GitHub / GitLab (cloud or self-managed).
Webhooks for push and (where enabled) pipeline events.
Tokens stored as secrets, never echoed in UI.

Outcome: Loopback can clone, discover, and react to changes with trust.

Stage B — Define the bundle (product identity)

Human-facing name and stable slug.
Link to repository and default branch policy.
Build hints: Dockerfile path, context, build args, optional multi-stage target.

Outcome: a durable anchor for service catalog entries inside your org.

Stage C — Discovery (turn unknown repo into a plan)

Discovery answers operational questions:

Where is the Dockerfile?
Is there a Helm chart? Under which path?
What ports are exposed?
What base images are referenced (policy/compliance)?

Failure handling: discovery is a state machine; fix the repo, rerun discovery, keep history.

Stage D — Environments (dev / stage / prod tracks)

An environment binds:

Workspace target (which cluster/namespace story receives deploy).
Values and manifest overlays appropriate to that track.
Optional cluster resource attachments your operator requires.

Outcome: parallel promotion tracks without copying the entire project.

Stage E — Revisions (immutable “what we built”)

A revision is your bill of materials for a point in time:

Commit SHA
Image digest (once build completes)
Readiness state

Outcome: answer compliance questions inside Loopback.

Stage F — Build

Build operations produce OCI images and push to a registry your operator configured (commonly Harbor-oriented flows).

Operational tip: treat failed builds like CI failures—fix Dockerfile, dependencies, or registry permissions; Loopback surfaces task failure in product workflows.

Stage G — Deploy (continuous reconciliation)

Deploy ties revision + environment to a rollout record and drives GitOps-style reconciliation into the workspace.

Outcome: fewer “works on my laptop” deploys; more declared state with background convergence.

Stage H — Undeploy / stop

Stopping a deployment should remove the continuous reconciliation hooks and mark the rollout stopped in product records—so you do not have zombie GitOps recreating workloads you thought you removed.

Part 3 — Comparison table (talk track for sales)

Legacy toolchain piece	How bundles cover the value
CI server	Build operations + revision records + integration webhooks.
Container registry	Image artifacts tied to revisions; promotion is traceable.
Helm values sprawl	Environment-scoped manifest material and discovery metadata.
Argo/Flux apps	Declarative reconciliation driven via Loopback automation (Flux-class in shipped path).
Change audit	RBAC + bundle operations history (confirm SIEM export with operator).

Part 4 — When bundles are not the right tool (yet)

Mobile builds, ML artifact stores, or non-container release trains may still need external CI.
Large monorepos with dozens of services may need multiple bundles or operator guidance on repo layout.
Air-gapped Git requires mirroring and egress planning up front.

Part 5 — Security and governance

Least privilege on Git OAuth scopes (read-only automation where possible).
Separate roles for build vs deploy vs prod promote.
Webhook secrets rotated on same schedule as CI secrets.
Registry credentials never pasted into tickets; use operator-managed secret flows.

Deep RBAC framing: Auditing and fine-grained access.

Bundles overview
Bundle operations (API)
Git OAuth and webhooks
Kubernetes applications - platform catalog vs your apps.
Workspaces overview
Technical verification