Create and publish a template
You need template.create permission in the active organization to create a template. Creation always starts private, so the team can review the application, variables, and defaults before sharing anything in the public catalog.
Before you start
Prepare an HTTP application with a public reference in one of the supported registries: Docker Hub, GitHub Container Registry (GHCR), Quay, or GitLab Registry. Use a tag or version that Zenifra can validate. The application must respond on the port you enter and, if it writes files, you should know which path needs persistence.
Separate the environment variables as well. For each variable, define its name, description, whether it is required, and whether it is secret. Never use a password, token, API key, or another sensitive value as a suggested value. The person deploying the template will enter it during deployment.
Step 1: open the form
- Open the Templates catalog.
- Confirm the active organization in the console selector.
- Select New template.
- Fill in the name, summary, description, and tags.
The name and summary appear on catalog cards. Use simple, descriptive tags such as web, cms, or productivity. Do not put internal identifiers, private URLs, or secrets in these fields.
Step 2: define the application
Enter the public application reference, the HTTP port, and, when needed, the persistent data path. The path must match where the application writes files that need to survive updates. Leave it empty when the application does not keep local data.
Then choose the suggested defaults:
| Setting | Meaning |
|---|---|
| Plan | Initial capacity selected for the project |
| Billing | Hourly, monthly, or yearly billing mode |
| Access | Public or private application exposure |
| Instances | Initial instance count |
| Persistence | Whether data is kept across updates |
| Capacity | Suggested persistent data capacity |
| Auto-scaling | Whether automatic scaling starts enabled |
These values are suggestions. The person deploying the template can review them before confirming the project.
Step 3: declare variables
Add one row for each variable expected by the application. Use uppercase names containing letters, numbers, and underscores. Mark a variable Required when the application cannot start without it. Mark it Secret for credentials, tokens, passwords, or keys.
Secret variables do not have suggested values. Even for non-secret variables, use defaults only for safe and generic configuration. The description should guide the consumer without revealing information about your organization.
Step 4: optionally declare a database dependency
Turn on the database option only when the application needs a new database to work. Choose one or more compatible engines from the current catalog, select the recommended engine, and provide one recommendation for every compatible engine. The catalog supplies the available plans, billing modes, versions, capacity limits, and other configuration fields, so the form remains current as new engines become available.
You can bind a declared variable to a connection detail such as host, port, database name, username, password, connection URL, or host and port together. Use a secret variable for a sensitive connection detail. Non-sensitive bindings can have a suggested value for an external database. When Zenifra creates the database with the application, it fills every binding from that new connection instead.
Do not enter a real password, connection URL, or other connection value in the template. The template stores the binding, not the value.
Step 5: review and publish
When saved, the template receives its first revision and remains private. Open its details and review the application, port, defaults, tags, and variables. When ready, choose Publish. Publication is immediate after application validation and makes the template visible in the public catalog.
If you want to keep it restricted to the organization, leave its visibility private. Later edits create a new revision. If someone saved an older revision, the console reports a conflict before replacing the current content.
The Official Template badge is not requested during publication. It identifies Templates from organizations recognized by Zenifra, including Zenifra itself and official partners, and appears automatically when applicable.