Welcome to Omega Cloud

You now have a private, isolated environment ("domain") on Omega Cloud. This document explains what we manage, what you manage, and how we work together.

What you received at handoff

Your domain: a hard isolation boundary. Nothing you create inside it is visible to any other client, and no other client's activity is visible to you.
Your administrator account (<you>-domain-admin): manages your team's users and projects inside your domain. This account and its scope are described in the Self-Service Guide.
Two workload accounts (-cluster and -svc) preconfigured the way the platform requires -- see the Self-Service Guide before changing anything about them.
A capacity envelope (quota) sized from your intake form.
Access to shared platform resources: the external network for public connectivity, base operating-system and Kubernetes images, and a set of machine sizes (flavors).

What we manage (and you cannot)

The cloud infrastructure itself, including the isolation between clients.
Your domain's existence, your administrator account, and password resets for it (there is deliberately no self-service recovery -- resets require a request from one of your named credential custodians).
Quotas. Your administrator cannot raise them; an authorized requester asks us instead.
The shared substrate: external networks, public base images, machine sizes.

What you manage (self-service, no ticket needed)

Everything inside your domain: team user accounts, projects, private networks and routers, firewall rules (security groups), virtual machines, storage volumes, load balancers, Kubernetes clusters, application secrets and certificates, and public IP attachments -- all within your quota.

How to reach us

Quota changes, password resets, custodian changes: request from an authorized requester (named in your intake form) via your account contact.
Incidents/outages: your account contact, marked urgent.
Everything else self-service: see the Self-Service Guide.

Your document pack (read in this order)

This welcome letter -- the split of responsibilities.
The Self-Service Guide -- how to run your environment day to day.
The Handover Pack -- your identifiers, accounts, endpoints, and the platform rules you acknowledge. This is the single reference for your specific values (endpoints, account names, network identifiers); the other guides point back to it rather than repeat them.
The CI/Automation Integration Guide -- if you connect pipelines or other automation.
The Jenkins + Kubernetes Implementation Guide -- if you run a Jenkins pipeline against a Kubernetes cluster; a single end-to-end workflow.
The Acceptance Checklist -- run it once at onboarding to prove your environment works.

The Handover Pack ends with a Glossary (plain-language definitions of every term used across the guides). The pack also includes a scripts/ starter kit (referenced throughout the guides) and, if your team uses an AI assistant, an AI assistant guide with its skill package.

Going straight to a task?

Each guide owns one workflow end-to-end, so you should not need to jump between documents to finish a task. Start at the one for your goal:

Run day-to-day (networks, servers, load balancers, secrets, users): the Self-Service Guide.
Look up one of your own values (an endpoint, account name, or network): the Handover Pack.
Connect a pipeline or other automation to the cloud API: the CI/Automation Integration Guide.
Stand up a Kubernetes cluster and deploy to it from Jenkins: the Jenkins + Kubernetes Implementation Guide.
Prove the environment works: the Acceptance Checklist.

House rules (the short version)

Never share account passwords between people; your administrator creates individual users instead.
Never ask us to grant "admin" on your accounts -- the platform will refuse, by design. Your -domain-admin account already has every right you need inside your domain.
Keep your two named credential custodians current with us.