Onboarding and Operations
From first call to production go-live — typically in 5–7 business days.
gh0stcloud onboarding is engineer-led with one clear goal: at the end of the process, the first tenant workload is running in production with active monitoring and configured alerts — without the customer having to touch a single infrastructure component.
Onboarding timeline
Phase 1: Discovery (day 1–2)
What happens:
- Kick-off call to clarify workload type, tier selection (Starter / Growth / Enterprise) and timeline
- Technical briefing: which services need to run, storage and networking requirements
- Contract sign-off and package confirmation
Outcome: Onboarding scope is documented in writing, tenant org is created in Keycloak.
Phase 2: Provisioning (day 1–3)
The gh0stservice team provisions all infrastructure:
- Keycloak Organization with initial admin accounts and invite links
- Isolated tenant namespace in the target environment — automatically created by our provisioning system
- Secrets area in OpenBao with initial credentials, exclusively accessible to your namespace
- RBAC — ServiceAccounts and bindings following least-privilege principles
- Admission policies — namespace labels, resource quotas and NetworkPolicies active automatically
Outcome: Namespace is live, Keycloak login works, observability starts collecting data.
Phase 3: GitOps setup (day 2–5)
Your Git repository is configured as a Flux CD source. From this point, every commit to your repository is the single mechanism to deploy changes into the cluster — no manual kubectl interaction, no direct cluster access.
What happens:
- Your repository is configured as a Flux source
- The first reconcile cycle is triggered and validated
- The deployment pipeline is tested end-to-end
- The tenant team runs their first deployment cycle
Outcome: First workload runs in the cluster, Flux CD reconciles automatically on every commit.
Phase 4: Go-live (day 5–7)
Pre-production checklist:
- All workloads reconcile successfully
- Observability active: metrics, logs and (optionally) traces visible in the portal
- Billing attribution visible in the FinOps dashboard
- Alert rules configured for critical services
- Tenant admin can independently trigger deployments and view logs
- SLA tier confirmed and active
Outcome: Production is live, gh0stservice monitors actively, SLA applies from this date.
Day-2 operations
| Change type | How it works |
|---|---|
| New deployment / update | Commit to tenant repository → Flux CD reconciles automatically |
| New secrets | Create entry in OpenBao → ESO syncs into namespace |
| Increase capacity | Ticket to gh0stservice → quota update via provisioning system |
| Book dedicated node | Contract extension → dedicated bare-metal server assigned exclusively |
| Platform updates | gh0stservice communicates maintenance windows, zero-downtime for tenant workloads |
No ops team needed on the tenant side
For normal operations, tenants need:
- Access to a Git repository (own or provided by gh0stservice)
- Basic Kubernetes/Helm knowledge for writing manifests
- Access to the gh0stportal
No cluster admin access, no infrastructure knowledge, no on-call shifts for platform issues.
Questions or ready to get started?
Talk to us