Deploying a Managed App¶

This guide walks through ordering a managed app from b'nerd's catalog, watching it come up, and the two day-2 operations available once it's running: changing its version and deleting it. The flow, the five-phase lifecycle, and the day-2 operations are the same mechanism for every managed kind — Managed Nextcloud is used throughout as the walkthrough example, with call-outs where Managed GitLab and Managed Keycloak (the other kinds available today) differ. For background on Stacks, visibility, and the credential model, see the Apps / Service Catalog — Managed apps reference.

Prerequisites¶

• An account with access to a project and the apps:create permission (see Roles & RBAC).
• The app kind you want must show as available in your organization's catalog. Contact your account manager if it doesn't.

1. Find the kind in the catalog¶

In the dashboard, open a project and go to Create new App. Kinds that need a Stack (like Nextcloud) show a small mono line under the description, e.g. 2 stacks eligible — a preview of what the next step will offer, before you commit to anything.

If the kind is available but no Stack currently supports it yet, the tile shows Available on request with a Contact support link instead of a live create link — the kind itself isn't gated, there's just nowhere to place it yet. b'nerd is notified when this happens.

Click the tile to start the create flow.

2. Step 1 — Kind¶

The create flow opens on a 4-step rail: Kind → Stack → Configure → Confirm. Step 1 shows the kind you picked as a read-only summary card (icon, name, kind value). Use change to go back to the catalog if you picked the wrong one, otherwise click Continue.

3. Step 2 — Stack¶

This step lists every Stack that's eligible for the kind you're deploying — servers your organization is authorized to use and that b'nerd has confirmed can run it. Each card shows the Stack's name, its visibility (public, shared, or private), and which cloud provider it runs on.

• Pick exactly one (radio selection).
• If only one Stack is eligible, it's pre-selected for you — you still see which one it is, there's just no decision to make.
• If none are eligible, you'll see "No stack currently hosts this kind" with a Contact support link rather than an empty or broken list.

Click Continue once a Stack is selected.

4. Step 3 — Configure¶

• Name — required. Becomes part of the instance's identity (and its eventual URL once it's ready).
• Version — a dropdown of available versions when the platform has published a version list for the Stack's operator; otherwise the step shows "Version is managed automatically (latest)" and there's nothing to choose yet. This fills in over time as more Stacks are set up with version metadata — don't be surprised if it isn't there on day one for every kind.
• Credentials — for kinds that need an administrator login (Nextcloud), a labeled Credentials section with an Admin password field. (For Nextcloud specifically, the admin username is fixed to admin — you only set the password.)
  • Click Generate to fill in a random value in your browser — it's revealed once, in monospace, with a copy button next to it.
  • The helper text under the section header is the whole story: "Stored as a Kubernetes Secret in the instance's namespace. Never shown again after you leave this page — save it now if you need it." There is no way to retrieve this value later, from the dashboard or the API — see Credentials are write-only for what happens to it after submission.
• GitLab (Managed GitLab) — this step looks a little different: instead of an admin password, you choose an Edition (Community or Enterprise, defaulting to Community). Community needs no credential at all. Enterprise adds a License field where you paste your license file contents — handled the same write-only way as any other credential, and required before you can continue.
• Keycloak (Managed Keycloak) — no credential to type in: the admin login is generated for you (or set your own, same as Nextcloud), plus, in Advanced, an optional root redirect path. Full field-by-field detail: Managed Keycloak.

Click Continue once a name is set (and, for GitLab Enterprise, a license).

5. Step 4 — Confirm¶

A read-only review of what you chose (kind, Stack, name, version — never the credential value again), plus an honest expectation about timing:

Creating this instance is asynchronous — it typically takes a few minutes. You'll see it here as requested, then provisioning, then ready.

Click Create instance. There's no separate success screen — submitting takes you straight to the instance's detail page, which is where you watch it come up.

6. Watch it come up¶

The instance detail page shows the lifecycle phase as a pill at the top — the single most important fact on the page:

The page also shows Last synced — when the platform last checked in on this instance. Status here comes from a short polling interval, not a live connection; if it's been more than a few minutes, the page tells you the status may be slightly out of date rather than pretending it's current.

7. Day-2: change the version¶

Once an instance is up, its detail page offers a Change version action:

1. Click Change version — opens a modal listing versions newer than what's currently running. Downgrades aren't offered.
2. Pick a version and confirm. The instance re-enters provisioning while the operator reconciles — the same lifecycle as a fresh create, just for an upgrade.

If no newer versions are listed, it's because the platform hasn't published a version list for that instance's Stack/operator pair yet — the same limitation noted in step 4 above, not an error.

8. Day-2: delete an instance¶

Deletion is a deliberate two-step process. Every instance is created with deletion protection on by default.

1. In the instance's Danger zone, turn off Deletion protection. This opens a confirmation asking you to type the instance's name — turning protection off by itself does not delete anything, it only makes the instance deletable.
2. With protection off, Delete instance becomes available. Click it, and type the instance's name again to confirm. The copy is direct about what happens: "This deletes the instance and its data. This cannot be undone."

Both confirmations require typing the exact instance name — there's no accidental single-click delete path for a managed app.

Troubleshooting¶

What's next¶