Skip to content
← Documentation
On this page

Templates & duplication

Environment drift is the problem where staging slowly stops resembling production, and reproducing a bug means rebuilding a project from memory. Templates and duplication exist to make "give me another one of those" a single action.

What a template is#

A template is a project's shape, saved without its contents. It records what a project is made of — which apps, pointing at which images or repositories, with which ports, resources and variables; which managed services, at which sizes; how configuration and secrets are laid out — and it records none of the running state. No pods, no database rows, no accumulated logs.

The distinction that matters: a template is not a backup and it is not a snapshot. Spawning a project from one does not restore data. It creates a new project with the same structure, whose databases start empty and whose apps deploy fresh. If what you want is your data back, a template is the wrong tool and a database backup is the right one.

It is also a point-in-time capture, not a live link. A template taken today does not change when the project it came from changes, and projects spawned from it do not track it afterwards. That is deliberate — a template that mutates underneath you is not a template — but it means a template you rely on needs re-taking when the original moves on.

The unit is a whole project rather than a single app, because the useful thing to reproduce is rarely one service. It is a service plus the database it talks to plus the configuration that connects them.

Duplicate copies a live project into a new one—right now, from the project you're looking at.

Save as template captures that same shape as a reusable template stored at the organization level. You can spawn new projects from a template whenever you need one, long after the original has changed.

Use duplication when you want a copy today. Use a template when you want a repeatable starting point. Both produce a real, independent project: unless you choose to reuse part of the original, the copy shares nothing with it, so a migration you run in it cannot touch the source's database.

Duplicating a project#

  1. Open the project and choose Duplicate.
  2. Name the new project and pick which server it should land on—it does not have to be the one the source runs on.
  3. Choose what to carry over: apps, configs and secrets, services, and domains.
  4. For each managed service, choose Empty, With data or Reuse, and for each app, Copy or Reuse. See below.
  5. Confirm.

Anyport creates the new project and recreates everything you selected inside it. The copy starts in dependency order, services before the apps that read from them, and the confirmation says the order it will use, such as postgres, redis → api → web.

Copy, seed or reuse#

  • Empty gives the copy a new instance of the service with its own storage and credentials. The default.
  • With data does the same and then restores the source's most recent backup into it. It needs the source service to have a backup destination; without one the option is disabled and says why. The copy's backups go to a directory of their own, and if the obvious one is already taken the review step says which one it will use instead.
  • Reuse gives the copy nothing new: its apps are pointed at the source's instance and read and write the source's data. For an app, reuse means the app is not copied or built at all, and the copy's other apps reach the original. Reuse is offered only when the copy lands on the same cluster, and the review step lists everything reused, because a second writer on the source's database is the point where a copy stops being independent.

With network isolation on, reuse opens exactly the path it needs, from the copy to the source and not the other way.

What to think about before you confirm#

  • Secrets. Duplication can copy real credentials into the new project. The confirmation step tells you exactly which secrets are involved—read it. Copying a production key into a staging environment is easy to do by accident and hard to undo.
  • Services. Unless you choose Reuse, managed services are recreated as new instances with their own storage and credentials, and the copy does not share a database with the original.
  • Domains. A generated hostname is issued fresh for the copy. A custom domain can only point at one place, so it stays with the original.
  • Auto-deploy. Decide whether the copy should redeploy on push. A duplicate that shares a repo with the original will otherwise rebuild every time that repo changes.

Templates#

Templates live at the organization level, not inside a single project, so any project in the organization can be spawned from one. Create a template from a project you're happy with, then use it as the starting point for new environments.

Because a template is captured at a point in time, it does not track later changes to the project it came from. If the source project moves on, create a new template from it.

One-click stacks#

Beside your own templates the gallery carries a curated set that ships with Anyport: Metabase, Umami, WordPress, Ghost, n8n and OpenClaw. Each asks two or three questions (a version, a disk size, an API key where one is unavoidable) and creates the project with its managed database, its generated secrets and its disk already wired to the app, published on a hostname that stays locked until you have been through the app's own setup.

Every stack is an anyport.yaml with questions in front of it: the same file format a repository carries, rendered with your answers and built through the same paths anyport apply uses. The one addition the stacks lean on is generate, on a secret's key or on a secret variable, which mints a random value for a signing key or a session secret the first time and never touches it again, so a stack needs no secret you have to invent. A credential a stack cannot invent, an API key for a model provider, is one of the questions in front of the file, and its answer lands sealed: never in the file, never shown again.

Pausing a project#

Related but different: pause scales a project's apps to zero without deleting anything, so a project you're not using stops consuming resources while keeping its configuration. Resume it when you need it again. Pausing is manual—Anyport will not pause a project on your behalf.

Next steps#