Publishing — from code to marketplace

You have a working actor and a green test suite. This chapter covers the last mile: build the image, push it to GHCR, register it in the Creator Hub, and get it through review to a live marketplace listing.

The whole funnel:

Build an image with config.json baked in.
Push it to a public registry (GHCR by convention).
Register the image URL on Kaoohi.
Kaoohi pulls the image and extracts your config.
Review approves the actor.
The actor appears in the marketplace and users deploy instances.

1. Build and push your image

Pre-flight

From your actor repo:

make kaoohi-config   # regenerate src/kaoohi/config.json + freshness check
pytest               # keep the suite green

src/kaoohi/config.json is derived from your Pydantic settings and the [tool.kaoohi] metadata in pyproject.toml — never hand-edit it. The Dockerfile bakes it into the image, and it is the exact file the platform reads back out of the image at registration, so it must be fresh before you build.

Tag before you build

Your actor’s version comes from git tags via hatch-vcs — there is no hardcoded version in pyproject.toml. Tag first, then build:

git tag v1.2.3

The Docker build cannot read .git/, so pass the version in explicitly as a build arg, without the leading v. Without it, the image falls back to 0.0.0:

docker build \
  --build-arg BUILD_VERSION=1.2.3 \
  -t ghcr.io/allcare/myactor:v1.2.3 .

The version surfaces in /health, /ready, and /api/actor/metadata, so reviewers and users will see it. Publish tagged builds only.

Push to GHCR

The template’s default repository convention is ghcr.io/allcare/<name>, with any underscores in your project name replaced by hyphens — this is the kaoohi_image_repo Copier variable. If you accepted the default at generation time, push there:

docker login ghcr.io
docker push ghcr.io/allcare/myactor:v1.2.3

The platform pulls the image itself to extract the config, so the image must be publicly readable on the registry.

2. Register the actor in the Creator Hub

First time: your kreator profile

If this is your first actor, create your kreator profile first — it is self-service from the platform. Once your profile is active, the Creator Hub appears in your sidebar.

The 3-step wizard

Open Creator Hub → Register Actor (https://<PLATFORM_URL>/home/creator/register-actor). The wizard has three steps:

Image reference — paste the full image URL, tag included, for example ghcr.io/allcare/myactor:v1.2.3, then click Extract Config. Kaoohi pulls the OCI image, extracts src/kaoohi/config.json from it, and validates it. You never paste config.json yourself — the platform reads it straight out of the image. It shows a parameter-count summary and warns above 50 parameters.
Preview & configure — review the summary, parameters, and deployment tabs. You can override the display name, description, category, and tags, and set your pricing model and price (see ](en/monetization/)).
Review & submit — Save as Draft or Submit for Review.

If extraction fails, the platform asks whether the image was built with the kaboum template. That is almost always the cue that config.json is missing or stale in the image — rerun make kaoohi-config, rebuild, and push a new tag.

3. What happens next: review

Every submission goes through a security scan and a use-case review. Your submission moves through these statuses:

Status	What it means	What you do
`draft`	Saved in the Creator Hub, not submitted.	Finish the wizard and submit when ready.
`pending_review`	In the review queue — security scan and use-case review.	Wait. Watch “My Actors”.
`approved`	Live in the marketplace.	Users can deploy instances. See below.
`rejected`	The submission did not pass review.	Rework the actor and submit again.
`revision_requested`	Reviewers want specific changes before approval.	Address the requested changes and resubmit.

Where to watch

You track review status in one place only: My Actors in the Creator Hub. There are no notifications yet, and no review SLA has been published.

On `revision_requested`

Read the requested changes, fix them, and if the fix touches code or config, push a new image tag before resubmitting — the platform always extracts the config from the image you reference, so the fix must be in the image, not just in your repo.

4. After approval

Once approved, your actor is listed in the marketplace and users can deploy instances. What the platform does from there:

Instantiation — when a user deploys your actor, they get a kompanion: one account’s running instance of your actor. The actor is the class; the kompanion is the instance.
Environment injection — the platform injects environment variables from the parameters in your config.json. Every parameter you declare becomes a setting the platform passes to the kompanion at instantiation.
Health and readiness gating — the platform checks /health and /ready before routing traffic to a new kompanion. The template declares a readiness probe by default; keep startup honest — fail /ready until the actor can actually serve.
The marketplace card — GET /api/actor/metadata on each kompanion serves the short card the marketplace shows: name, description, version, capabilities. It comes from the same config you registered, so an honest config.json is an honest card.

Publishing an update

When you submit a config update on an already-approved actor, the live listing keeps serving the old config until the update is re-approved. Plan your releases accordingly — an update is never instant.

Where to go deeper

kaboum launching new actors guide — full walk-through from copier copy to production
kaboum API reference — every endpoint your image serves
kaoohi Creator Actor Guide (documentation/01-user-guide/Creator-Actor-Guide.md in the kaoohi repo) — the platform-side registration flow
Next: ](en/monetization/) — pricing models, revenue share, and what is coming