Package a running service

Use packaging when a verified runtime should become a re-importable Zerops bundle. It is a handoff or reuse task after the app already works, not the normal way to deploy the next change.

You can ask for it directly:

Package appstage as a buildFromGit import bundle.
Commit it and push it to git.

The result is a single git repo that contains the app source, zerops.yaml, and a project import file named zerops-project-import.yaml. The import file uses buildFromGit: so a fresh Zerops project can rebuild the app from the repo instead of carrying source code inside YAML.

Packaging starts from a deployed Zerops runtime. If important source changes exist only on your laptop, deploy or push them first so the runtime and git repo match what you want to package.

When to package

Package a runtime when you need:

• a running runtime and its managed dependencies reproduced in another Zerops project,
• a reusable starter, demo, handoff, customer project, or clean staging baseline,
• a repo commit that carries the Zerops import shape next to the app source,
• the destination project to build from git.

Do not use packaging for:

• the next app deploy; use the normal build, deploy, and verify loop,
• the production release; production needs its own infrastructure, credentials, domains, and release trigger,
• moving managed-service data; backups and restores are separate.

For production setup, follow Promote to production. Packaging can help create a reusable app bundle, but it does not decide production infrastructure or release policy.

What the agent prepares

The agent packages one runtime. If the project has dev and stage runtimes, it asks which one to use because they can have different env values, start commands, or setup: blocks.

Managed services come along as dependencies when the runtime's zerops.yaml needs their env references. You do not pick databases, caches, queues, or search services one by one.

The workflow then prepares:

• zerops-project-import.yaml - the project and service shape for the destination project,
• zerops.yaml - the runtime build and run configuration,
• a git commit and push when git delivery is configured or explicitly requested.

If the runtime has no usable zerops.yaml or git remote, the agent has to fix that first. A bundle is only useful when the destination project can pull source and build it from git.

Env vars need review

Project env vars are the main place where the agent may ask you to decide. Each value gets one bucket:

Bucket	Use for	Bundle result
infrastructure	Values derived from managed services, such as database or cache references.	Omitted from project envs; the new managed service provides fresh values.
auto-secret	App-owned signing or encryption keys that can be regenerated.	Fresh generated secret on import.
external-secret	Third-party credentials such as Stripe, OpenAI, Mailgun, or GitHub.	REPLACE_ME placeholder.
plain-config	Literal non-secret config such as log level, feature flags, or public app settings.	Copied as-is.

Do not treat this as a key-name guessing game. The agent should inspect source code and ask when classification changes behavior. For example, regenerating a Laravel APP_KEY, Django SECRET_KEY, or session secret can break existing encrypted state. If state continuity matters, carry the existing value instead of generating a new one.

What is not included

Not included	What to do instead
Managed-service data	Restore from Backup or another migration path.
Real third-party secrets	Fill placeholders in the destination project before deploying.
Production domains, scaling, backups, and release triggers	Configure them in the destination project.
A repeatable production release process	Use your CI or release workflow; see Promote to production.

Use the bundle

After the bundle is pushed, import zerops-project-import.yaml in the destination project through the dashboard or with zcli project project-import zerops-project-import.yaml.

Before opening the new project to users:

• fill REPLACE_ME values,
• restore or seed data when needed,
• review service scaling and public access,
• run a normal deploy and verification pass in the destination project.