Platform overview

Prerequisites: None. This page is the starting point.

This page explains what Clouve is, how it is built, and what happens between a developer submitting an application and a business user's deployment running in production.

What is Clouve?

Clouve is a Kubernetes-native, multi-cloud enterprise marketplace. Developers package a containerized application once and make it available to businesses, who deploy it to managed Kubernetes clusters on GCP, AWS, Azure, or private infrastructure without having to manage containers, networking, or Kubernetes themselves. In practice, Clouve is a self-service platform that sits between a developer's Docker image and an enterprise's cloud account.

Core concepts

Application

An application is a deployable unit made up of one or more containers. A WordPress application, for example, consists of a wordpress container (the main frontend app) and a wordpress-mariadb container (the database). Both are deployed together into a Kubernetes namespace.

Marketplace manifest

Every application in the marketplace has a marketplace manifest: a clv-docker-compose.yml file that extends the standard Docker Compose format with x-clouve-* extension fields. These fields carry the metadata the platform needs to generate Kubernetes manifests, expose the right ports, manage secrets, and show the app correctly in the marketplace UI.

The standard Docker Compose portion of the file works with regular docker-compose tooling, so developers can test their apps locally without anything Clouve-specific.

Container configuration

Before an application can be deployed, every container in it must be fully configured. That means specifying:

  • Which Docker image to run
  • What port it listens on
  • How much CPU and memory it needs
  • Which environment variables it requires, and their types
  • Whether it needs persistent storage
  • How to health-check it

You can enter this configuration through the Clouve UI (Step 2 of the submission wizard) or upload it as a Docker Compose YAML file. Both methods are equivalent.

Bundle

A bundle is a marketplace listing that contains multiple independent, publicly accessible applications. An "Education Kit" bundle might include both Moodle (LMS) and Gibbon (school management): each is reachable on its own subdomain and usable on its own, while the two share infrastructure.

Namespace

Each deployment runs in its own Kubernetes namespace, named with the pattern org-<org-id>-<ticket-id>. This gives complete isolation between organizations and between different deployments within the same organization.

End-to-end flow

Developer path (publishing an app)

Developer
    │
    ▼
1. Package app as Docker image(s)
   └─ Build and push to registry (e.g., Docker Hub, GCR)
    │
    ▼
2. Create marketplace manifest (clv-docker-compose.yml)
   └─ Defines containers, env vars, volumes, health checks
    │
    ▼
3. Submit application in Clouve UI
   ├─ Step 1: Basic information (name, description, version, icon, category)
   ├─ Step 2: Container configuration (the UI or YAML upload, plus the
   │           permanent AI Assistant tab)
   ├─ Step 3: Infrastructure & pricing (aggregated resources, tier preview)
   ├─ Step 4: Version management (impact analysis on updates)
   └─ Step 5: Review and submit
    │
    ▼
4. Platform review
   └─ Validation of manifest, image accessibility, configuration completeness
    │
    ▼
5. App appears in marketplace

Business user path (deploying an app)

Business User
    │
    ▼
1. Browse marketplace
   └─ Find and evaluate an application
    │
    ▼
2. Click Deploy
   ├─ Select target workspace/cluster
   ├─ Fill in user-configurable settings
   └─ Set application credentials (username/password)
    │
    ▼
3. Platform provisions deployment
   ├─ Generates Kubernetes manifests
   ├─ Applies manifests to target cluster
   ├─ Kubernetes pulls images and starts containers
   └─ Ingress and TLS configured automatically
    │
    ▼
4. Application is live
   └─ Accessible via https://<workspace>.clouve.dev

Infrastructure under the hood

When a business deploys an application, the platform:

  1. Creates a Kubernetes namespace: org-<org-id>-<ticket-id>
  2. Creates Kubernetes Secrets for secret and applicationPassword variables
  3. Creates Kubernetes ConfigMaps for everything else: static, userConfigurable, containerReference, applicationUsername, applicationUrl, and applicationHost
  4. Creates a Deployment (for stateless services) or StatefulSet (for Database, Cache, or Message Queue purposes) per container, using the configured image, resources, and environment
  5. Creates a Service for each container (ClusterIP for private, LoadBalancer / Ingress for public)
  6. Creates an Ingress with TLS termination (cert-manager + gcp-prod) for each public container
  7. Creates PersistentVolumeClaims for each defined volume
  8. Synthesizes the agent service block at deploy time, if the application opted into the AI Assistant (Magneto Agent). The developer's saved manifest stores only the x-clouve-agent toggle and the skills source, not the full agent shape.

All DNS is managed through GCP Cloud DNS, and TLS certificates are issued automatically by cert-manager using the gcp-prod issuer (Google Public CA).

Authentication and multi-tenancy

  • Users authenticate with an email and password, Google OAuth 2.0 (Passport.js) or OIDC.
  • All data is scoped to organizations. An organization owns its workspaces, deployments, and data.
  • Kubernetes namespaces keep resources fully isolated between organizations.

Next steps