Developer onboarding

Prerequisites: A basic understanding of Docker and Docker Compose.

This page covers what you need to work as a Clouve developer: creating your account, learning the submission flow, and setting up a local environment to test applications before you publish.


Overview

As a Clouve developer, you publish containerized applications to the marketplace and configure their deployment behavior with clv-docker-compose.yml manifests. After publishing, you manage versions and updates and support the business users who deploy your apps.

Going from first login to a published app typically takes a few hours for a simple single-container application, and a day or two for a complex multi-container bundle.


Step 1: Create your account

  1. Go to the Clouve platform URL provided by your organization or the Clouve team.
  2. Sign in with your email and password, or click Sign In with Google.
  3. On first login, you will be asked to complete your profile (name, organization, role).
  4. Request developer access if your account does not already have it. This enables the application submission workflow.

Note: Standard user accounts can deploy applications but cannot submit new ones to the marketplace. Publishing requires developer access.


Step 2: Understand the submission wizard

The submission wizard is a five-step form reached from the developer dashboard.

Step 1: Basic information

  • Name: the display name shown in the marketplace (e.g., "WordPress", "Moodle LMS")
  • Short description and extended description: what the application does, shown to business users
  • Category: the marketplace category (CMS, CRM, Education, etc.)
  • Visibility: who can see and deploy the listing: Public (everyone), Organization (only members of your organization) or Private (only you)
  • Tags (optional)
  • Icon: the application logo (PNG, recommended 256×256 px), required; screenshots are optional

Step 2: Container configuration

Most of the technical work happens here. You define all the containers your application needs: images, ports, resources, environment variables, health checks, and storage. Container configuration covers this step in detail.

The permanent AI Assistant tab in this step is where you opt in to (or stay out of) the platform-synthesized agent sidecar. See Magneto Agent / AI Assistant.

Step 3: Infrastructure & pricing

You set one number here: the Developer Monthly Fee, the amount you receive per subscriber each month. Clouve adds its hosting cost for each capacity tier, based on the resources your containers add up to (memory in GB, CPU in cores, total storage), plus the flat AI Assistant fee if you enabled it. The pricing preview shows each part and the total a customer pays on each tier. The AI Assistant fee is a separate line item; it is not aggregated into the container resources.

Step 4: Version management

Set the release's version (semantic, e.g. 1.0.0) and a changelog. For update submissions, this step also shows which fields changed since the previous published version and the severity of each change (LOW / MEDIUM / HIGH).

Step 5: Review and submit

A summary of everything you've configured. When you submit, the platform validates your configuration and queues it for review.


Step 3: Set up your local environment

Test your application locally before you submit it. The Clouve packaging format is designed to work with standard Docker tooling.

Required tools

ToolVersionPurpose
Docker24+Build and run containers
Docker Composev2+Run multi-container apps locally
A text editorAnyEdit YAML manifests

Recommended tools

ToolPurpose
yamllintValidate YAML syntax before uploading
hadolintLint your Dockerfiles
diveInspect Docker image layers

Test your app locally

Every application in the Clouve marketplace should work with docker-compose up before you package it:

# From your application directory
docker-compose up

# Or for a clean start (useful for testing initialization scripts)
docker-compose down -v && docker-compose up

If your app doesn't work with plain Docker Compose, it won't work on the platform either.


Step 4: Understand the file structure

Every Clouve marketplace application is stored in the magneto service under apps/<app-name>/:

apps/
└── my-application/
    ├── README.md                    # Documentation for your app
    ├── logo.png                     # App logo (256×256 recommended)
    ├── docker-compose.yml           # For local development and testing
    ├── clv-docker-compose.yml       # Marketplace manifest (what the platform reads)
    └── image/                       # Custom Docker image source (if needed)
        ├── Dockerfile
        ├── build.config
        └── installer/
            ├── entrypoint.sh
            └── install.sh

Two files matter most:

  • docker-compose.yml: a standard Docker Compose file for local testing. It needs no Clouve-specific fields.
  • clv-docker-compose.yml: the marketplace manifest, a Docker Compose file extended with x-clouve-* fields that the platform reads at deployment time.

See the Containerization guide for how to create these files.


Step 5: Know the review process

After you submit an application:

  1. Automated validation: the platform checks that all required fields are present, images are accessible, and the configuration is valid.
  2. Manual review (if applicable): a platform administrator reviews the app for security and quality.
  3. Approval: the application status changes to APPROVED and it becomes visible in the marketplace.
  4. Rejected: if validation fails or the review finds issues, you'll receive feedback and can resubmit.

You can track submission status from the developer dashboard.


Step 6: Understand versioning

Each submitted application has a version number that follows semantic versioning (MAJOR.MINOR.PATCH). When you update your app:

  • Patch updates (1.0.0 → 1.0.1): bug fixes, no breaking changes
  • Minor updates (1.0.0 → 1.1.0): new features, backward compatible
  • Major updates (1.0.0 → 2.0.0): breaking changes

Business users who have deployed your app get a notification when an update is available. They can update or stay on their current version.


Common mistakes to avoid

MistakeImpactFix
Using latest tag for imagesUnpredictable deploymentsAlways use a specific version tag
Not testing locally firstFailed deploymentsRun docker-compose up before submitting
Missing x-clouve-metadata on all containersDeployment failureEvery container needs the metadata block
Using container names with underscoresDNS naming failureUse hyphens only: my-app, not my_app
Forgetting to mark secrets with type: secretSecurity exposureReview all sensitive values before submitting

Next steps