Skip to Content
Documentation
ApplicationsTemplates quick guide

Application templates

A template creates a stack: one or more connected application services deployed to an existing resource pool. This quick guide remains available at its original URL. The dedicated Templates documentation covers installation, authoring, and maintenance in detail.

Detailed guides

A template contains a reviewed stack configuration, application icon, setup questions, and maintenance instructions. Browse Templates, open the application page, and review its publisher, version, services, resource requirements, and external dependencies.

Deploy a template

  1. Choose Deploy application on the template page.
  2. Sign in and select a workspace and project.
  3. Choose an environment and resource pool with the required architecture and capacity.
  4. Answer the configuration questions. Generated secrets are created privately for the new stack.
  5. Review the services and allocations, then select Deploy application.

A template does not create a free server. Applications share the CPU, memory, and storage in the selected resource pool. Pool charges and external service charges follow their respective billing arrangements. A resource recommendation is a starting point; workload requirements vary.

Deployment uses the selected release snapshot. New template releases do not automatically update installed stacks. Advanced configuration changes are recorded as a customized configuration while retaining the original release identity.

Create a publisher

Open Publishing in your workspace. The workspace owner can create the publisher, choose a public name and stable handle, and delegate template editing or publisher administration to accepted workspace members. Publisher access is checked again when workspace membership changes.

Public profile changes are reviewed. Private account contact details and verification evidence are not published.

Prepare and submit a template

Choose Create template, supply its name and slug, and upload an application icon. Use an upstream icon only when you have permission to distribute it.

Icons accept static PNG, JPEG, or WebP images up to 5 MB. Infralane converts them to PNG and removes embedded metadata. Draft images stay private; a reviewed published release exposes its selected icon. Each publisher can upload up to 100 images per day.

The editor includes:

  • Application name, summary, category, tags, edition, upstream version, source, software license, configuration license, and support links.
  • A supported Compose configuration, minimum resource recommendations, and declared Linux architectures.
  • Labeled configuration inputs, generated secrets, optional defaults, allowed choices, and private database connection URLs built from other inputs.
  • Description, getting started, operations and backups, and release notes in Markdown with Write and Preview modes.
  • Optional uploaded screenshots with alternative text.

Raw HTML, executable embeds, and remote Markdown images are excluded. URLs must use HTTPS. Public templates use pinned public container images; source builds and private pull credentials are not supported in public releases.

Save the draft, choose Resolve image versions, inspect the pinned configuration, and attest that the configuration and assets may be published and contain no real credentials. Then choose Submit for review. Submission freezes the candidate; subsequent draft edits do not change it.

Review and publication

Staff inspect the exact candidate and compare it with the previous release. Review includes configuration validation, rights and brand assets, image scan evidence, and installation and persistence evidence for every declared architecture. Application tests are performed in disposable isolated infrastructure; the staff portal records their results and report references.

A reviewer can request changes, reject a candidate with a reason, or approve it once required evidence is current. Ordinary reviewers cannot approve or publish their own candidates; a superuser exception still requires the same evidence and audit controls. Publisher verification does not bypass this process.

Read review messages in the template’s publishing page and reply there. Staff-only investigation notes are excluded. A changed candidate needs a new template version and review. You can withdraw an eligible pending submission.

Publisher verification

After an accepted template demonstrates maintenance, a publisher administrator can request verification from Publisher profile. Provide ownership, maintenance, and support evidence. Domain verification uses the DNS TXT challenge shown in the dashboard; equivalent source-control ownership evidence can be reviewed by staff when DNS proof is unsuitable.

Verified publishers receive a checkmark valid for up to one year. Identity changes, suspension, expiry, or revocation remove it. Staff review new releases from verified publishers through the same approval process.

The checkmark indicates reviewed publisher identity and maintenance evidence. It does not establish an upstream partnership or guarantee software security.

Maintenance and advisories

Installed stacks show their originating publisher, release, and customization state. Read the template’s backup and upgrade instructions before changing application versions.

Staff can unlist, archive, deprecate, or block templates and releases. Blocking prevents new registry installations and stops further service submissions when availability is checked. An already accepted deployment cannot be recalled by a registry decision. Running services and persistent data are retained. Installed-stack members receive applicable release advisories through their notification preferences.

Use Report a problem on the dashboard template page to report deployment failures, outdated configurations, security concerns, impersonation, or licensing concerns. Exclude passwords, access tokens, and private logs.

Last updated on