Create and publish templates

Publish a reusable configuration when you can explain how to install, operate, back up, and maintain the application. A public template is a versioned bundle of configuration, permitted assets, setup inputs, and documentation. Publication requires staff review of the exact submitted bundle.

1. Create a publisher

Open Publishing in the workspace, or Manage publishing from the dashboard Templates page. The workspace owner enables publishing by providing a public publisher name, stable handle, and HTTPS website or project page.

The handle forms the publisher namespace. Use a unique name starting with a lowercase letter and containing up to 40 lowercase letters, digits, or hyphens. Reserved names are unavailable. Your public publisher identity is separate from the private workspace name.

Public profile changes are submitted for review. Customers see the approved profile; private contact details and verification evidence are not published. A public profile must be approved and the publisher active before a template release can be published.

2. Delegate publishing access

Under Publisher profile → Publisher members, the owner or a publisher administrator can grant accepted workspace members one of these roles:

Workspace membership alone does not grant template editing. Publishing access is checked again against current workspace membership. Removing publishing access does not imply deleting the workspace member. Staff review rights are separate from publisher roles.

3. Create the template identity

Select Create template, enter the application name and Template slug, and upload an application icon. The slug becomes part of /templates/publisher-handle/template-slug; choose a clear, stable identity.

Use icons and screenshots only when you have permission to distribute them and represent the upstream project accurately. A recognizable logo is not evidence of an official partnership.

Image requirements

SVG and animated images are not accepted. Draft assets remain private. Published release pages expose the assets selected in that reviewed snapshot. Replacing a published icon or screenshot requires a successor release.

4. Describe the application and requirements

Complete the authoring sections with accurate information:

• Application name and short description: explain what this configuration deploys; the summary is limited to 160 characters.
• Category and tags: select an available category and up to eight short tags.
• Upstream name, version, and edition: distinguish the software being packaged from your template release version.
• Website, source, license, and support links: use public HTTPS URLs without credentials or custom ports.
• Configuration license: identify your permission terms for the configuration itself, separately from the upstream software license.
• Required external services: disclose dependencies such as SMTP, provider accounts, commercial licenses, or third-party services and their separate setup or charges.
• Resource requirements: CPU, memory in MB, storage in GB, and assumptions behind those recommendations.
• Tested architectures: declare amd64, arm64, or both only when evidence supports each architecture.

Do not use sample resource values as measured production capacity. Requirements must fit the actual configuration and describe expected data growth or workload assumptions.

5. Author supported Compose

Use the Stack Compose reference. Public releases have these additional rules:

• Every service uses a public prebuilt container image pinned to a reviewed sha256 digest.
• Dockerfile/source-build services are not supported.
• Private registry credentials, private repository references, and per-service repository/branch settings are excluded.
• Secret environment values use whole references such as ${DATABASE_PASSWORD} to declared private inputs.
• All non-literal input references must have input definitions.
• Named volumes and readiness checks must match the application’s persistence and startup requirements.

Use Resolve image versions after saving the draft to resolve public Docker Hub or GHCR references to immutable image versions. Inspect the resulting configuration before submission. Image resolution pins a reference; it does not run a vulnerability scan or an installation test.

Do not invent a digest to satisfy the format. Review the actual resolved images, their upstream origin, supported architectures, and applicable license.

6. Define the setup inputs

For each input, provide an uppercase key, visible label, type, helper text, and value behavior. Supported behaviors include customer-provided values, optional safe defaults, generated secrets, and privately derived database URLs.

Inputs should answer real setup questions. For example, label an input Administrator email and explain where the application uses it. Do not label it only with an internal variable name. Never include a real credential as a default.

See Template input reference for types, validation, generation, and a complete derived-URL pattern.

7. Write usable documentation

The editor offers Write and Preview for Markdown. Include these documents:

Description, getting started, and operations documentation are required for submission. Include release notes for changes even though an initial draft can have empty notes.

Use ordinary Markdown headings, lists, links, tables, and code blocks. Raw HTML, executable embeds, unsafe URLs, and remote Markdown images are excluded. Add screenshots through the supported upload fields with alternative text. Use fictional examples, never customer data or real credentials.

8. Save, resolve, and submit

1. Select Save draft. Saving a draft does not change public content.
2. Select Resolve image versions and inspect the pinned manifest.
3. Preview the documentation and check every image, link, resource requirement, and declared input.
4. Attest that you have permission to publish the configuration and assets and that the template contains no real credentials.
5. Select Submit for review.

Submission freezes the candidate and its content hash. Later draft edits cannot change that submitted release. A template version such as 1.0.0 can only identify one submitted snapshot; changes after submission need a new version, even if an earlier candidate was withdrawn, rejected, or returned for changes.

Only one eligible unpublished candidate can remain pending at a time. Resolve or withdraw it before submitting a successor. If another session edited the draft, reload and compare the latest revision before saving or submitting again.

9. Follow the review

Open the template’s publishing page to read release status, review reasons, and messages. Reply with the requested context and redacted evidence. Publisher-visible conversations exclude staff-only notes. Eligible pending submissions can be withdrawn without changing published releases.

Review includes:

• Static metadata and Compose validation against the production compiler.
• Rights and brand-asset review.
• Actual image-scan evidence for every declared architecture.
• Installation evidence from fresh, isolated infrastructure for every declared architecture.
• Persistence evidence showing retained-volume recreation and data recovery behavior for every declared architecture.

The review portal records evidence; it does not execute submitted applications. Scans and installation/persistence tests are operator-run. Verification or an approval checkbox does not replace actual checks. Ordinary reviewers cannot approve or publish their own submission; a superuser exception still requires the same evidence and audit controls.

Staff can request changes, reject with a reason, or approve an eligible candidate. Approval and publication are separate states unless staff perform the combined action. A release becomes public only after publication. See Release lifecycle.

10. Request publisher verification

After an accepted template demonstrates maintenance, a publisher administrator can use Publisher profile → Publisher verification:

1. Save any pending profile edits first.
2. For DNS proof, enter an Owned domain and select Create ownership challenge.
3. Add the exact TXT record and value shown in the dashboard at your DNS provider, then select Verify DNS record.
4. Describe identity, maintenance, and support ownership in Identity and maintenance evidence.
5. Select Request publisher verification.

When domain proof is unsuitable, provide source-control ownership evidence for staff to review. Do not invent a TXT token or reuse an unrelated application’s domain verification record.

Verification can remain valid for up to one year. Expiry, revocation, suspension, or relevant identity changes can remove the checkmark. Verification does not bypass release review, certify application security, or establish an upstream partnership.

Maintain what you publish

Monitor upstream changes, respond to reports, update operations instructions, and submit new reviewed versions when configuration changes. Installed stacks never auto-upgrade. Use the maintenance guide to understand advisories, blocked releases, and customer upgrade responsibility.