One stack. One platform.

Kubernetes with one provider. S3-compatible object storage with another. Container images in a separate registry. Deployments managed through additional tools.

Each service does its job. The challenge starts where they need to work together: identities, permissions, resource management, and operations.

Loopback brings Kubernetes, object storage, an OCI registry, and deployments together on one platform. The underlying standards remain unchanged. Management becomes centralized.

One shared platform architecture

In a typical multi-provider architecture, every infrastructure service has its own management layer.

You provision Kubernetes clusters in one provider console. S3 buckets and access keys live in another system. The container registry maintains its own users and access rights.

Loopback takes an integrated approach.

The platform provides a shared management layer for organizations, projects, resources, and permissions. Different infrastructure products can be managed without changing their technical interfaces.

The architecture separates two areas:

• Central platform management: Loopback manages organizations, accounts, groups, RBAC, and billing.
• Infrastructure and workloads: Kubernetes clusters and storage resources run with the selected providers and in the selected locations.

Central platform data is hosted in Germany. You choose where Kubernetes workloads and storage resources run by selecting the provider and location.

This brings different infrastructure components under one management model.

Kubernetes stays Kubernetes

Kubernetes orchestrates containerized applications. Loopback provides a highly available control plane and private networking.

You choose your cluster's infrastructure provider and location, then manage nodes, scaling groups, and other cluster resources through the platform.

The integration uses the standard Kubernetes API, not a proprietary Kubernetes variant.

Cluster capabilities include:

• Highly available Kubernetes control plane
• Private networking with Cilium as the CNI
• Scaling groups with configurable autoscaling logic
• One-click upgrades
• Admin Kubeconfig and OIDC Kubeconfig
• Persistent volumes through the provider's CSI driver

Existing Kubernetes manifests, Helm charts, and tools remain usable.

Loopback provisions and manages the cluster infrastructure. The Kubernetes API remains the interface for your applications.

Explore Kubernetes.

S3-compatible object storage

Many applications need persistent storage outside the Kubernetes cluster.

Object storage can hold uploaded files, generated artifacts, and application data accessed through an object-based interface.

Loopback integrates S3-compatible object storage into the same management environment as Kubernetes.

You can create public and private buckets, manage access keys, and use familiar S3-compatible clients and SDKs.

Buckets belong to your Loopback project and can be accessed by applications in the cluster.

Multiple S3 providers are available. The storage location follows your selected provider.

The S3 interface stays the same. Storage resources are managed through Loopback.

Explore Object Storage.

OCI Registry for application artifacts

Container images and Helm charts are essential to modern deployment workflows.

The Loopback Registry manages these artifacts through OCI- and Docker-compatible repositories.

It supports public and private repositories across the organization, rather than limiting them to a single Kubernetes project.

For automated access, robot accounts provide permissions including pull, push, and combined access rights.

This lets existing build and deployment workflows use standard registry interfaces.

At the same time, the registry is integrated with the platform's central permissions model.

Artifacts, technical credentials, and organizational access rights can therefore be managed within one structure.

Explore the OCI Registry.

RBAC across product boundaries

One of the most important architectural differences is how identities and permissions are managed.

In a distributed setup, each service often has its own access model.

One team member needs access to Kubernetes, another to storage buckets, and a CI/CD process to the container registry. When these services operate independently, access must be managed separately.

Loopback provides central role-based access control (RBAC).

Accounts belong to organizations. Within an organization, you can manage memberships, groups, and fine-grained permissions.

Each product defines its own permissions, managed through the same RBAC system.

Teams can organize access to Kubernetes, object storage, the registry, and other platform functions centrally.

Authentication options include SSO, external identity providers, OTP, and passkeys. API tokens support programmatic platform access.

Central RBAC does not replace the native authentication mechanisms of each standard. Kubernetes retains its access mechanisms, S3 uses access keys, and the registry supports its own credentials.

One RBAC model for the platform. Standard interfaces for the services.

From GitHub to Kubernetes deployment

Bundles connects application management to the underlying infrastructure products.

A Bundle represents an application deployed directly from GitHub.

You can manage multiple environments and configure different sources for the application and Helm charts.

An integrated chart builder, deployment history, and deploy, rollback, and undeploy controls complete the workflow.

Container images pushed through a Bundle automatically land in the Loopback Registry.

This connects deployment control and artifact management while Kubernetes remains the runtime environment.

Explore Bundles.

Keep standards. Centralize infrastructure management.

An integrated developer platform does not need proprietary runtimes or new interfaces.

Loopback builds on established technologies:

• Kubernetes as the API and runtime for containerized applications.
• S3 as the compatible interface for object storage.
• OCI as the standard for container images and artifacts.
• RBAC as the platform-wide permissions model.

Products can be used individually or combined into a larger infrastructure stack.

Start with a Kubernetes cluster, add object storage later, and then manage your container images through the registry.

Your organization, user management, and billing remain on the same platform.

This reduces the number of independent management systems and provides a consistent foundation for operating modern applications.

One stack. One platform.

Modern infrastructure consists of specialized services. That specialization is useful and remains intact.

What does not need to be rebuilt for every service is the administrative layer above it.

Loopback connects Kubernetes, S3-compatible object storage, an OCI registry, and deployments within one European Developer Platform.

Open standards for your applications. One platform to operate them.