Quick Start Guide

What this page is for

The shortest useful path through Fenwave, in two tracks: setting the platform up as an administrator, and getting productive as a developer. Follow the one that matches your job.

Before you start

You are signed in — see Access the Platform. Beyond that, the two tracks have different prerequisites, listed in each.

The two tracks

Administrator setup

The order matters — each step consumes what the previous produced. Doing it out of order is the standard first-day mistake.

1. Settings › General — apply the licence key, set branding and the support contact.
2. Settings › People & Access — add the administrators who will do the rest. Create their roles first; a user without a role signs in to an empty platform.
3. Settings › Infrastructure › Cloud — register the cloud account and validate it.
4. Settings › Infrastructure › Clusters — register the clusters and validate each. Prefer IRSA, Pod Identity or Workload Identity over a static token.
5. Settings › Infrastructure › Environments — create dev, staging and production on those clusters. Until they exist, no policy can be scoped to them.
6. Settings › Development › Repositories — connect the Git repositories and validate them. With SSH, install the public key as a deploy key on the provider.
7. Settings › Development › CI/CD — connect both Argo CD and Argo Workflows. Deployments use one, pipelines the other; connecting only one leaves half the platform inert. Test each.
8. Settings › Development › Projects — declare projects and components so they appear in the catalog with owners.
9. Settings › People & Access › Policies — now that clusters and environments exist, create scoped policies and the roles that carry them.
10. Verify with Access Explorer before telling anyone it is ready.

Step 9 must come after steps 4 and 5: a policy cannot be scoped to a cluster or environment that does not exist yet, and an unscoped policy grants everything.

Developer first steps

1. My Space › My Profile — confirm your account and set your language.
2. My Space › My Groups — check your team’s group.
3. Explore › Catalog — find your team’s components.
4. Explore › Architecture — see how they fit together.
5. Build › Create an Application — if you are starting something new.
6. Deploy › Dev — create an ephemeral environment for your branch and deploy.
7. Environment Detail — read Events before Application Logs. Events tells you whether the platform succeeded; logs only matter once it has.

Scenario

From an empty install to a developer shipping to dev, in one afternoon.

1. Work through Administrator setup steps 1 to 8.
2. Create one scoped policy — deployment permissions, limited to the dev cluster with the environment condition set to dev.
3. Create a Developer role carrying only that policy. Do not hand out admin as a shortcut: it bypasses policies entirely and picks up every cluster added later.
4. Add one developer with that role and the Dev profile.
5. Have them sign in and follow Developer first steps.
6. When they report they cannot do something, use Access Explorer with their username and the exact permission from the error — not a description of what they tried.
7. Once one developer works end to end, the rest is repetition.

Proving the whole path with one person before onboarding ten is what turns a long afternoon into a short one.

When it doesn’t work

Next

• Settings — the full administrator reference
• Deploy — the developer’s daily surface