Signing in, switching and finding your way

This page covers the three things you do every day: signing in, switching between accounts or roles, and getting around.

Signing in

You sign in on the address your hosting runs under. That is the address your hosting provider gave you — panel1.corecp.dev, say, or your reseller's own. The sign-in screen carries that provider's name, logo and colour; it is not a different product, it is the same panel under a different name.

1. Enter your email address and password.
2. If you have a passkey on this address, your browser or device asks for it.
3. If you have no passkey but do have two-step verification, enter the six-digit code from your app.
4. You land in the context you were in last time.

Three things worth knowing:

• One password, everywhere. Your email address is your identity. If you work with two hosting providers who both run CoreCP, that is one password — but on each address you only see what belongs there. Neither provider ever learns that you are the other one's customer.
• Paste always works. Password managers are not fought.
• Lost is not locked out. Setting up a passkey gives you recovery codes. Keep them; they are the way back when the device is gone.

If you forget your password, the panel sends a reset in the branding of the same address — never naming another provider.

The first time, when your level requires two-step verification

Administrators and server administrators must have a second factor. If you have not got one yet, your very first sign-in looks like this:

1. You type your email address and password and press Sign in.
2. The password is right, but you are not in yet: your session is half a session until there is a second factor.
3. So you do not land on the dashboard but straight on Set up two-factor authentication — with a QR code, the key beneath it to type by hand, and a field for the code from your app.
4. Scan the code, enter the six digits, press Activate.
5. You get your recovery codes. Keep them; this is the only moment they are shown. Press I have saved them and you are in.

You cannot skip this step and you only do it once. If you would rather use a passkey later, add one under My account → Sign-in & security; see Securing your account.

Did this stall for you? Up to and including panel version 0.17.6 the sign-in screen simply stayed put at this step: no error, no redirect, as if nothing had happened. There was nothing wrong with your password — the screen sent you to the enrolment page without first saying you were half way, and the guard on that page put you back. From 0.17.7 you land where you belong. If it still stalls, tell us which panel version is at the foot of the sidebar.

From the command line the same state is visible in the API's answer: state is totp_required and enrol_totp is true.

curl -s -X POST https://panel1.corecp.dev/api/v1/auth/login \
  -H 'Content-Type: application/json' \
  -d @- <<'JSON' | jq .
{"email":"admin@example.com","password":"…"}
JSON
#   {"state":"totp_required","enrol_totp":true,"passkey_nag":true}

The password is in a here-document rather than behind -d '…': anything you pass on the command line is readable in /proc by every other user of that machine.

The panel's language

The panel speaks Dutch and English. The NL / EN switch is in two places, and both set the same thing:

• on the sign-in screen, top right beside the light/dark control;
• in the account menu, at the foot of the sidebar, behind your email address.

What a press does:

A language you choose before signing in stays. Your choice is carried through the sign-in and recorded on your account; it is not overwritten by whatever your account happened to hold. That is the difference between a choice and a guess: if the panel once worked your language out from your browser, your press beats it — including a press made on the sign-in screen.

If it cannot be recorded — a flaky connection, the panel briefly out of reach — you are told, and your choice is kept: the next time you open the panel it tries again. A language that disappears without anyone saying so should not exist.

The second row is the difference that matters. A language you chose yourself is your choice from then on: the panel never again guesses one from what your browser happens to ask for, and signing in on a borrowed computer no longer changes it. That same choice is the language of every system email — see Email we send you.

The same setting, with more explanation around it, is also under Settings → Appearance. There is no difference between the two: it is one preference.

Did your language keep snapping back to English? Fixed in 0.17.7. The switch in the bar changed the language on your screen but never told your account — so the next time the panel read your account back, the old language returned. Choose your language once more and it stays.

Switching account or role

Top left, directly under the product name, is the account switcher. It is on every screen, deliberately: the context decides what every number on the page counts.

Each row shows:

• the name of the account or group;
• what you are there — Administrator, Reseller, User;
• temporary when your access has an end date.

Click a row to switch. You do not sign in again: you already held the authority of both contexts, and the panel changes hats. You land on the new context's overview — the page you were on would mean nothing there.

If you have only one context there is nothing to choose — but the switcher is still a button. Press it and a short panel says what this context is: the name, your level, the group it belongs to, and an end date if your access is temporary. Underneath, one sentence explains that this is where you switch context as soon as you hold more than one. A piece of text that answers nothing leaves you guessing whether it is a control; this panel answers.

Switching is off while you are signed in as somebody else. Press the switcher then and the same panel explains why rather than only showing a padlock. A bar at the top of the screen says "you are signed in as …" with one button to stop. Stop first, switch after.

On your phone

The switcher is in the slide-out menu too: tap More at the bottom and it is at the top, in the same place as on a large screen — under the brand name, above the menu items. Switching works there exactly as it does elsewhere. (Until this version it was not there at all, so on a phone you could not see which context you were in.)

Next time you sign in, you come back to the context you used last.

What you can reach: the account, not the server

What a context lets you reach depends on two things — and since 10 August 2026 on exactly those two and no third:

1. the hosting account is in your realm (the root realm, or your reseller's);
2. it is yours, or one of your customers' if you are a reseller.

The machine the account sits on does not count. That sounds obvious and was not: until 10 August 2026 the machine was asked as a third ownership question, so the moment you were a customer of a reseller while the server sat in the root group, you got 403 node_out_of_scope on your own website — on mail, DNS, FTP, files, backups and WordPress alike. That is gone. For administrators and server administrators the machine still counts, because they manage machines; see Where a website is served.

Nothing became wider. If you notice otherwise — you can see something that is not yours, or you cannot reach something that is — report it, because then something is broken.

Checking what your session may do, from your own computer:

# sign in and keep the session
curl -sk -c /tmp/corecp.jar -X POST https://panel1.corecp.dev/api/v1/auth/login \
  -H 'Content-Type: application/json' \
  -d '{"email":"owner@test100.nl","password":"..."}' >/dev/null

# who you are, and in which realm
curl -sk -b /tmp/corecp.jar https://panel1.corecp.dev/api/v1/auth/session | \
  python3 -c 'import json,sys;u=json.load(sys.stdin)["user"];print(u["email"],u["level"],u["organization_name"])'

owner@test100.nl user Reseller Test BV

# and which hosting accounts that yields
curl -sk -b /tmp/corecp.jar https://panel1.corecp.dev/api/v1/accounts | \
  python3 -c 'import json,sys;[print(r["account"]["username"]) for r in json.load(sys.stdin)]'

demo

One account, because one is yours — and it sits on a machine in the root realm, which you notice nowhere. A reseller sees more from the same command, an administrator sees all of them.

Finding your way

The skeleton is the same for everybody; you simply see fewer entries if you may do less.

⌘K (or Ctrl-K) opens the command palette. Type part of a name and you jump straight there: a hosting account, a server, or one of the actions — email, DNS, backups, a rollout, a terminal. It is an accelerator, not a hidden feature: everything in it is also in the menu.

The bell at the top right collects what happened: a rollout that halted, a task that finished, a backup that failed. A failure also appears once as a transient message; everything else waits quietly in the bell.

From the command line

If you would rather type, corectl on the panel server does the same:

# Which contexts does a person hold, and where are they now?
corecp-panel identity status

# Who may sign in as somebody else (the right is off per membership)?
corecp-panel admin impersonation list

# Grant (or withdraw) the right to sign in as somebody else
corecp-panel admin impersonation allow axel@xynta.nl

The API has the same two steps as the switcher:

# Which contexts do I have on this address?
curl -s https://panel1.corecp.dev/api/v1/auth/contexts \
  -H "Cookie: $COOKIE" | jq '.contexts[] | {label, level, membership_id}'

# Switch to one
curl -s -X POST https://panel1.corecp.dev/api/v1/auth/context \
  -H "Cookie: $COOKIE" -H "X-CoreCP-CSRF: $CSRF" \
  -H 'Content-Type: application/json' \
  -d '{"membership":"<membership_id>"}' | jq '.user.level'

The session you get back replaces the old one; the old one is revoked immediately.

Into webmail and phpMyAdmin without signing in again

The buttons that take you to webmail or phpMyAdmin open a tab and sign you in there with a single-use ticket that lives ninety seconds. The ticket travels in the form body and never in the address bar, so it is in neither your history nor anybody's log.

For a while those buttons did nothing: the tab opened and stayed on "Signing you in…". The cause was one of the panel's own security rules, which forbids a form to submit to another address. The panel keeps that rule — it protects you from exactly the abuse it was written for — and now carries the sign-on through an address of its own, the only response that holds that one exception.

What you notice: the tab opens, says briefly what it is doing, and lands in webmail. If it takes too long it says so, with a button to try again, instead of hanging.

# the check that keeps it working, in a real browser
node corecp-panel/web/scripts/ui-flow-signon.mjs --url=https://panel1.corecp.dev
#   ok   the tab went on to webmail.test100.nl — the sign-on is allowed to leave

Into wp-admin, without signing in again

Alongside webmail and phpMyAdmin the same holds for your WordPress sites: under Websites → WordPress, in a site's own panel, there is Open wp-admin. A new tab opens and lands, a second later, inside that site's administration — signed in.

All three buttons work the same way: the tab opens at the moment you click — which is why your browser lets it through — and is sent to the right place afterwards. If no new tab appears, your browser is blocking pop-ups for the panel; allow them for this site.

You never get to see the key behind such a button, and that is deliberate: it works once, and whoever holds it gets in.