Publish an application

Decide the runtime, public operations, and user experience before entering the wizard.

• Prepare a stable name and slug.
• Prepare an external HTTPS endpoint or pullable image.
• Choose Load Balancer or Queue for hosted apps.
• List operations, examples, and expected durations.
• Prepare listing media, support information, and pricing.

Enter the name, slug, tagline, and full description. Treat the slug as a stable identifier. Explain inputs, outputs, limits, and billable behavior in the description.

Choose External API or platform hosting, then Load Balancer or Queue for a hosted release. Configure the image, port or handler, timeouts, workers, and environment.

• Validate the HTTPS endpoint for External API.
• Validate port, health, and operation paths for LB.
• Validate SDK registration, heartbeat, handler, and results for Queue.
• Provide secrets through environment or secret configuration rather than the image.
• Create and verify a new release after runtime changes.

Set a non-negative invocation price and optional free allowance. Pricing should match actual operations and disclose any secondary costs the application may incur.

This step configures both Marketplace listing media and the interactive entry users open. Icons, screenshots, and category shape the product detail page. Experience settings decide which frontend opens after Use now.

A Gradio template and a self-hosted frontend are two frontends for the same agent application. They are not two runtimes and not two model-invoke paths. Runtime (External / Load Balancer / Queue) is chosen in step 2. Experience is configured here and stays independent from runtime.

Provide at least one interactive experience: Gradio YAML, an external experience, or both. Worker and Endpoint addresses are for application calls. The experience URL is a browser-reachable frontend address.

• Upload an icon and screenshots, choose a category, and optionally add homepage, docs, and support links.
• Gradio YAML is optional; when it is empty, an external experience URL is required.
• External experience is optional and can be enabled together with Gradio.
• Experience URL is the developer frontend address over HTTP/HTTPS. Configure it separately from Runtime Endpoint and Worker addresses.

{
  "version": "1",
  "mode": "platform",
  "renderer": "gradio",
  "yaml": "version: \"1\"\nrenderer: gradio\n...",
  "external": {
    "mode": "embed",
    "url": "https://app.example.com",
    "fallback_url": "https://app.example.com"
  }
}

// Gradio only     -> mode=platform, renderer=gradio, no external
// External only   -> mode=external, external.url required
// Both            -> mode=platform + external (recommended for rich apps)

Both frontends target the same application backend. The difference is the user entry and call path, not business ownership.

• Gradio writes go through application Invocations. The platform routes the current release to Load Balancer or Queue.
• A self-hosted frontend adapts the application business APIs directly. Full product UX does not need to fit inside declarative YAML.
• When the app needs chat, image, or video generation, the server uses GRIDNEXA_AI_API_KEY and POST /v1/invoke.
• One application can expose both frontends: Gradio for in-platform trial, self-hosted UI for the complete product.

Gradio frontend
  browser -> platform experience page
          -> POST /v1/apps/{applicationId}/invocations
          -> Load Balancer worker OR Queue handler
          -> application business logic
          -> (optional) POST /v1/invoke when AI is needed

Self-hosted frontend
  browser -> application /api/*
          -> application business logic
          -> (optional) POST /v1/invoke when AI is needed

Marketplace and developer detail Use now / Open experience share one priority: a valid external experience URL wins; otherwise fall back to Gradio or a legacy platform template; if neither exists, launch is unavailable.

• embed embeds inside the platform experience page; link leaves to the developer site.
• When both are configured, the experience page defaults to the external frontend. Switch with ?view=platform or ?view=external.
• Before submit, click primary and secondary entries with a real user identity and verify response binding, async states, and downloads.
• Async flows should cover queued, running, completed, and failed states in addition to the synchronous success path.

Use now priority

1. external.url present?
   - link  -> open external URL in a new tab
   - embed -> /marketplace/product/{id}/experience
             (default view = external iframe)
2. else Gradio / platform template?
   -> /marketplace/product/{id}/experience (Gradio)
3. else unavailable

When both exist:
  ?view=platform  -> Gradio
  ?view=external  -> external embed

Review the listing, runtime, price, and experience. Submission moves the app to pending_review. It appears in the Marketplace after both the app and target market reach published.

• Complete one Invocation using a user identity.
• Check error responses and logs for keys, runtime tokens, or internal URLs.
• Retain requestId, Invocation ID, and worker logs.
• Address rejection reasons and resubmit the draft.

Each publication creates a separate release. Create and check a new version when changing images, manifests, operations, or experience configuration, then switch the active release. Unpublished applications stop accepting new public invocations.

draft -> pending_review -> published
                    |-> rejected -> edit -> pending_review

published -> unpublished
published / unpublished -> draft (edit and release again)