Learning paths / Deploy on ComputeSphere / How ComputeSphere is organised

Accounts, projects, environments and services

Reading · 6 min · Module 2, lesson 1 of 423 min left in this module

Module 2 · How ComputeSphere is organisedLesson 1 of 4

Goal: Draw how your own app would be organised on ComputeSphere, from the account down to each running service.

3:22 · captions and chapters · narrated with an AI-generated voice
Transcript

Narration uses an AI-generated voice.

[00:00] Where we're going

By the end of this video, you'll know where everything you run on ComputeSphere lives, and how to find it. It all sits in one chain. Learn it once, and every screen makes sense.

[00:12] The chain

At the top is your account. That's who pays, and who's in. Inside it, a project. One project holds one product, like a shop. Inside the project, environments. Say, staging and prod, each one a separate copy. And inside each environment, the services. Each one is a running part of your app, like a web server, or a background worker. Every service runs on spherelets. Each spherelet is one running copy. Each level lives inside the one above it. That's the whole idea.

[00:50] Account

Here it is in the console. This is the account overview. Your account's name sits down here, with your role. This one's the owner. The account is where billing lives. One subscription, one card, one set of invoices. It's also where your teammates join.

You can belong to more than one account, say your employer's and your own. Each one bills separately.

[01:17] Project

Next, projects. This account has one project, savanna. A project groups the services that make up one product. It doesn't run anything, or cost anything, by itself.

Open it, and here's what's inside. Its services on the left, and its environments on the right. A good rule: if two things ship and break together, they belong in the same project.

[01:44] Environment

This project has one environment, called dev. An environment is an isolated place for services to run. It has its own network, secrets and limits. So production can't read a staging password. And every service lives in exactly one environment. Here's ours, lagoon, a web service. Want the same app in staging and in prod? That means deploying it twice, once into each.

[02:13] Service and spherelets

Now the service itself. It's Running, and it has its own web address. Look at the path at the top. Project, then service. And its environment is right here, under its name. This is the deployment ID. It identifies this service, in this one environment.

And in its settings, here are its spherelets. One Flex spherelet. That's one running copy of the app. You'll learn more about spherelets later in this module.

[02:44] Recap

So, a quick recap, with what we just saw. Your account pays, and holds your team. A project holds one product. An environment is one isolated copy of it. And a service is one running part, on its spherelets. Find that chain, and you can find anything.

Now try it on paper. Pick an app you've built, or one you want to build. Write down its project, the environments you'd want, and each service it needs. I'll see you in the next lesson.

Key idea

Everything you run sits in a chain: account, project, environment, service. Each level lives inside the one above, so learn the chain once and every screen and command makes sense.

Account: who pays, and who's in

The account holds billing (one subscription, one card, one set of invoices) and its members. You can belong to several, say your employer's and your own, and each bills separately.

Project: one product

A project groups the services that make up one product: a shop, a marketing site, an internal tool. It doesn't run anything or cost anything by itself.

A good rule: if two things ship and break together, they belong in the same project.

Environment: one copy of the product

An environment is an isolated place for services to run, typically staging and prod. Each has its own network, secrets and limits, so production can't read a staging password.

Every service lives in exactly one environment. Running the same app in staging and production means deploying it twice, once into each.

Service: one running part

A service is one part of your app: a web server, a background worker, a scheduled job. It runs one container image, a packaged copy of your app and everything it needs, named like learn-hello-web:1.0.0. The part after the colon is the image tag, which says which build of the image to use.

A service runs on spherelets, one running copy each. Lesson 5.2.3 covers them.

Versions and the deployment ID

Each deploy records a version of the service: its image and settings at that moment, listed in its deploy history. Rolling back puts an earlier version back in place.

The deployment ID is what csph prints after a deploy. It identifies the service running in one environment, and commands like csph deployments rollback take it.

What records a version, and what doesn't

A version is recorded when the service is created, when you run csph deploy (even with the same image), and when a build from your repository deploys.

Saving a setting in the console doesn't record one; the setting goes into the next version you deploy. Restart, stop, start and scaling don't record one either. A rollback doesn't create a version; it makes an earlier one current again (lesson 5.7.4).

Try it on paper

Pick an app you've built or want to build. Write down one project name, the environments you'd want, and each service it needs. You'll choose types for those services next.

Check yourself

Your shop needs a staging copy and a production copy of the same web service. How many services do you deploy?

In the docs