> ## Documentation Index
> Fetch the complete documentation index at: https://docs.slipway.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Signing in

> Sign in with your email and a password, or through GitHub or GitLab.

slipway has two kinds of sign-in, and an account can hold both:

* **Email and password.** Register with a username, an email address and a password. This is the whole flow on the mobile apps, and it works on the console too.
* **GitHub or GitLab.** OAuth sign-in, which also connects the provider account your organizations deploy from. See [Connecting GitHub and GitLab](/organization/providers).

The sign-in screen is email-first: enter your address and press **Continue**. If a password account exists for that address, the password prompt appears; otherwise you land on registration with the address already filled in.

## Creating an account with email

Pick a **username** (3 to 30 characters: lowercase letters, digits and inner hyphens), enter your email and choose a **password** of at least 8 characters. slipway emails you a **6-digit code**; enter it to verify the address and you are signed in, with a default workspace ready. The code expires after 15 minutes and allows 5 attempts — use **Resend code** if it lapses.

You cannot sign in with a password until the address is verified. If you try, slipway mails a fresh code and sends you to the verification screen.

Usernames are permanent, and they are what the product shows wherever a GitHub or GitLab handle would appear: member lists, deploy attribution, activity feeds.

## Resetting a password

**Forgot password?** on the sign-in screen emails a 6-digit reset code (the answer is the same whether or not an account exists, so the form can't be used to probe addresses). Enter the code first; once it checks out you choose the new password, and that signs you in — and signs out **every other session and device**, including mobile apps and CLI tokens, since a reset is the account-recovery path.

To change your password routinely, use **Account → Change password** while signed in; that keeps other sessions alive.

## Adding a password to an OAuth account

If you signed up through GitHub or GitLab, **Account → Set a password** enables email sign-in for the same account. If slipway has never verified your address, it mails a code first; password sign-in stays locked until the code is entered on the sign-in page.

An email account and an OAuth account that happen to share an address stay **separate accounts** — slipway never merges identities on an email match. To attach a provider to your existing account, sign in first and then connect the provider from within the app.

## Two-factor authentication

Email/password accounts can add an authenticator app (1Password, Google Authenticator, Authy, and friends). Set it up from **Account** on the console or **Settings** in the app: add the key to your authenticator, confirm with a first code, and sign-ins ask for a fresh code from then on. Turning it off requires a current code, so a stolen session can't quietly remove the second factor. Secrets are stored envelope-encrypted with the platform key.

## Sign-in history

**Account → Security** on the console (and **Account → Sign-in history** in the app) lists every time your account was signed in: when, roughly where the request came from, the IP address, and whether it was a browser or the mobile app. The row that created the account is marked too, so the list has a beginning.

If you see a sign-in you do not recognise, change your password and use **Sign out everywhere** — that ends every browser, CLI token and mobile device, including the one you are on, so whoever else is holding a session loses it.

The location is best-effort and is only ever as precise as a city: it comes from the IP address, so a VPN or a mobile network can place you some distance from where you actually were. An entry with no location at all simply means we could not resolve one.

History covers the **last 90 days**. Your most recent sign-in is kept beyond that, so an account that has been dormant for a year still shows when it was last used.

## Emails involved

Two transactional emails power this flow, and both are editable in the operator's email admin: `auth.email_verification` (the signup/verify code) and `auth.password_reset` (the reset code). They bypass unsubscribe preferences because signing in depends on them.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.