- 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.
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.