Publishing

Prerequisites: Containerization guide, Container configuration

This page covers the full lifecycle of a marketplace application: initial submission, review, versioning, updates, and deprecation.

The submission process

The submission wizard

The wizard has five steps, each rendered by Wizard/StepRenderer.jsx:

Step 1: Basic Information

The version is set in Step 4.

Step 2: Container Configuration

Configure all containers as described in Container configuration. Before proceeding, confirm that:

• All containers have x-clouve-metadata
• All containers have x-clouve-healthcheck (even if disabled)
• All containers have x-clouve-environment-types (even if {})
• All public containers have appropriate health checks enabled
• Secrets are typed as secret

The permanent AI Assistant tab sits at the end of the container tab row. Leave its toggle off for a standard application; switch it on to opt into the platform-synthesized agent sidecar. See Magneto Agent / AI Assistant.

Step 3: Infrastructure & Pricing

Enter the Developer Monthly Fee: the amount you receive per subscriber each month. This is the only value you set on this step.

The step then previews the deployment's aggregated resources (memoryBase in GB, cpuBase in cores, total storage) and, for each capacity tier, the price a customer pays: your fee, plus Clouve's hosting cost for that tier, plus the flat AI Assistant fee if the AI Assistant is enabled. The AI Assistant fee does not roll up into the aggregated container resources; calculatePricingTiers computes it separately. The step also surfaces validation errors if the resource totals don't match an available tier.

Step 4: Version Management

For update submissions, this step shows a version-impact analysis: which fields changed since the previous published version and the severity of each change (LOW / MEDIUM / HIGH). For a brand-new application, the step prompts you to confirm the starting version.

Step 5: Review and Submit

A summary of everything you have configured, and your last chance to review before submitting. Things worth double-checking:

• Container names use hyphens, not underscores
• Images use specific version tags, not latest
• The public container is marked isPublic: true
• Database containers are marked isPublic: false
• Resource allocations are reasonable (the Review step shows the aggregated GB / vCPU totals)

Click Submit to send for review.

Validation

When you submit, the platform runs automated validation.

Schema validation:

• All required x-clouve-* fields are present
• Field values match expected types and formats
• Container names follow naming conventions (lowercase, hyphens, ≤63 chars)
• Volume sizes include units

Image accessibility:

• The platform attempts to verify that declared Docker images are reachable
• Images on private registries require credentials to be configured in advance

Configuration completeness:

• At least one container exists
• At least one container is public (for single-app submissions)
• The naming convention is followed (supporting containers prefixed with the main app name)

If validation fails, you get specific error messages describing what to fix. Fix the issues and resubmit.

Application status lifecycle

Draft → Submitted → Under Review → Approved → Published
                  ↓
               Rejected → (fix) → Resubmit → ...

Once published, the application appears in the marketplace for the audience its visibility allows (everyone, members of your organization, or only you) and can be deployed. You can change the visibility of a published listing later.

Earnings and payouts

Customers pay Clouve each month for the tier they deploy. Your share is the Developer Monthly Fee you set, per subscriber. Payouts are made through PayPal, and your developer dashboard shows your active subscriptions and monthly revenue.

Versioning

Every submission has a version number. Follow semantic versioning:

Version number rules:

• Format: MAJOR.MINOR.PATCH (e.g., 6.7.1)
• Optional suffix: 1.0.0-beta, 2.0.0-rc.1
• No v prefix (1.0.0 not v1.0.0)
• Each version must be higher than the previous

Updating an application

To update a published application (new image version, configuration change, bug fix):

Process

1. Go to your application in the developer dashboard
2. Click Create New Version
3. Enter the new version number
4. Make your changes in the wizard (metadata, container configuration)
5. Download the updated YAML for version control
6. Submit for review

What business users see

Business users who have deployed your app are notified when a newer version is available. They choose when to update; the platform never forces an update.

Update impact

• Container configuration changes (new env var, changed resource limits): applied on the user's next update
• Docker image tag changes: the new image is pulled when the user updates
• Breaking changes: consider providing a migration guide in the application description or release notes

Image management

Naming and tagging

Always use specific, immutable tags:

✅ myapp/backend:2.3.1
✅ wordpress:6.7.1
✅ postgres:16.4

❌ myapp/backend:latest   (changes over time)
❌ myapp/backend:stable   (ambiguous)

Registry requirements

Images must be accessible to the platform at deployment time:

• Public Docker Hub images: always accessible (e.g., nginx:1.27, postgres:16)
• Custom public images: hosted on Docker Hub, GCR, or any accessible registry
• Private images: require credentials to be pre-configured with the platform team

Updating image versions

When a new version of an upstream image is released:

1. Test your application with the new image version locally
2. Update the image tag in your manifest
3. Submit as a patch version update (e.g., 1.0.0 → 1.0.1)

Pre-submission checklist

Use this checklist before every submission.

Images

• All images use specific version tags (no latest)
• Images are accessible from the platform's network
• Images are built for linux/amd64

Container names

• All names are lowercase, alphanumeric + hyphens
• All names are 63 characters or fewer
• Supporting containers are prefixed with the main app name

Container configuration

• Every container has x-clouve-metadata
• Every container has x-clouve-healthcheck (with an explicit enabled: value)
• Every container has x-clouve-environment-types (or {})
• Volumes have corresponding entries in x-clouve-volumes

Security

• All passwords and keys are typed secret
• No real credentials in the manifest (use placeholders)
• Database containers are isPublic: false

Health checks

• Public containers have health checks enabled
• initialDelay accounts for startup time
• Health endpoints return 2xx when healthy

Volumes

• Mount paths match what the image expects
• Volume sizes include units (Gi, Mi)
• Volume names match between service volumes, x-clouve-volumes, and top-level volumes:

Metadata

• Version number is higher than the previous submission
• Description is accurate and informative
• Icon is provided (256×256 PNG)

After publishing

Once your app is approved:

• Deploy it yourself to verify it works end to end from the business user perspective
• Watch early deployments for patterns in support requests that suggest documentation or configuration improvements
• Track upstream image releases and submit updates promptly for security patches
• Business users may report issues; address them in new versions

Deprecating an application

To remove or replace an application:

1. Submit a final update marking the application as deprecated in the description
2. Contact the platform team to remove it from new deployment listings
3. Existing deployments continue to function; they are not deleted automatically

Next steps

• Troubleshooting →: diagnose and fix submission and deployment errors
• Bundles →: publishing multi-app bundles