What you can do yourself

You have a hosting account with a hosting company. For most things you do not have to call them: your mail, your DNS and your security certificates are yours to run, in the panel, without waiting for anybody.

Written for: Customer, Reseller

This page says exactly what "yourself" covers — and where the line is, so you are not hunting for a button that is not there.

You do this yourself

Email

Create a mailbox on your own domain.
Remove one. The panel asks separately whether the messages should go with it; leave that off and the mail stays.
Change a mailbox's password or its quota.
Set or clear an out-of-office reply.
Open webmail without signing in again.
Turn deliver this domain's mail here on or off. Off means your mail goes to somebody else (Google, Microsoft, whoever). Your mailboxes stay where they are, so it is always reversible.

DNS

Add or replace a record in your own zone — A, AAAA, MX, TXT, CNAME.
Remove one.

Security (SSL)

Request a certificate for your own website. One button, Request certificate; the panel handles the request and the renewals after it.
Install a certificate you bought somewhere else.

Databases

Create a database, generate a database login, grant or revoke its access, and have a new password made.
Open phpMyAdmin without a second password.

And

Your own files, FTP logins, SSH keys and backups.

You ask your hosting company for this

Not because it is difficult, but because it falls outside your own account or outside your own plan:

What	Why
Adding or removing a website	It changes what your plan contains and costs.
A website's PHP version	It comes from what the machine has installed.
A dedicated IP address for a website	Addresses are the hosting company's to hand out.
A forwarder or an alias	Not released for self-service yet.
Creating, moving or signing the DNS zone itself (DNSSEC)	The zone is the service; the records in it are yours.
Dropping a database	The one button on that screen that destroys data with no way back.

Not seeing one of those buttons is not a fault: the panel does not show buttons you would not be allowed to press.

Why you never end up in somebody else's account

Everything above hangs off your account. The panel works out whose the account is before it works out what you asked for; if the account is not yours it stops there, with account_out_of_scope. That holds when you edit the address bar too — the boundary is in the server, not in the screen.

Working with a colleague or an agency inside your account? Their profile decides what they may do: Mail management reaches your mailboxes and not your zone, DNS management the other way round, and Read-only never changes anything. See Giving somebody access.

For administrators: checking this

The boundary lives in one place in the code, and it can be read from outside it:

# the whole matrix of routes × kinds of caller
corecp-panel authz --check

# what a customer session gets on one route
grep -A3 '"route": "mailbox.create"' \
  corecp-panel/internal/panelapi/authz_matrix.json

And this is how the acceptance run proves it against a live panel — four times allowed, and twice refused where it should be:

bash scripts/e2e-r2-ui-hosting.sh 2>&1 | sed -n '/end user creates/,/alias.create/p'