# The people who sign in to your app

> Learn what hosting gives a login and what stays your app's job. See where a session lives and what a release does to it.

Source: https://customhosted.com/logins/

№ 01 Logins

Every page on this site explains hosting. This one explains the login your own app presents to its users — what hosting supplies for it, and what stays your job.

№ 02 Three different logins

## "Login" means three different things on this site

Only the third one is this page's subject.

- CustomHosted staff — Ours — Who on our side can touch production — a named account, two-factor, and a capability matrix. [Access](https://customhosted.com/access)
- Your team — Yours — There is no hosting console for your team to sign in to at all — a briefed change goes through the quote channel instead, not a dashboard login. [Access](https://customhosted.com/access)
- The people who use what you built — Your app's users — The login your own application presents to its visitors — the subject of this page.

№ 03 What a login needs

## What a login needs, and who supplies it

Six things any login needs, wherever it runs — hosting supplies some, your application supplies the rest.

1. 1 — HTTPS on every request — A password or a session token is only as safe as the connection carrying it — every route on every plan is served over TLS. [Delivery](https://customhosted.com/delivery) — CustomHosted
2. 2 — A place to keep the session — In memory, on disk, in a database, or in a signed cookie — your application picks the store, and the store decides what survives a restart. [Databases](https://customhosted.com/databases) — You
3. 3 — Outbound mail for a reset — A password-reset message rides the same outbound path as any other mail your app sends. [Email](https://customhosted.com/email) — You
4. 4 — A secret for an identity provider — An API key, a database password, a signing key, a connection string. [Configuration](https://customhosted.com/configuration) — You
5. 5 — A limit on repeated attempts — Nothing at the edge counts failed attempts against an account. A lockout or a rate limit on your own login endpoint is a check your code has to make. [Under attack](https://customhosted.com/under-attack) — You
6. 6 — A record of attempts — What a visitor typed or posted is not written down. Only that a request happened, and what came back. So a password never reaches a log here. What your own app records about a sign-in, and for how long, is its own decision. [Logs](https://customhosted.com/logs) — You

№ 04 By hosting shape

## What holds a login, by hosting shape

The surface grows only as real code and a real database enter the picture — the same rule the perimeter draws for an attacker.

- **Static**: No login exists. No standing server, so nothing here can hold a secret at all. A call to an outside service has to run from the visitor's own browser, out in the open. That's fine for a map or a widget. Never for a payment key. So a login on a static plan is always an outside service, called from the browser.
- **Dedicated**: Your code owns the whole login. It checks the password, it starts the session, and it enforces the attempt limit. The instance gives that code somewhere to run; the platform supplies none of it.
- **Dedicated plus a database**: The session store gets a real home — a users table, a sessions table, or both — instead of living only inside the running process.

№ 05 Where a session lives

## Where a session lives, and what ends one

The one fact this page exists to state plainly: a release restarts a dedicated instance, so a session held in its memory ends there.

| Where it lives | Survives a release | What that means |
| --- | --- | --- |
| In the instance's memory | No | A single dedicated instance has no second copy standing by to take traffic while the new version starts. A release is a short, health-checked restart, not an instant handoff between two running copies. Everyone signed in is signed out the moment the process restarts. |
| On the instance's disk | Only sometimes | A restart leaves it alone, but a rebuild of the instance replaces the disk under it — the same rebuild any other change to a dedicated instance can trigger. |
| In the database | Yes | A database tier is a separate, durable store from the instance running your app — a release does not touch it. |
| In a signed cookie | Not applicable | Nothing here holds it at all — the session data rides in the cookie itself, in the visitor's own browser. |

№ 06 Four ways it breaks

## Four ways a login breaks, with an owner each

Every one of these has a page that owns the fix — this page only names which.

- The reset mail does not arrive — Whether a message lands in an inbox, a spam folder, or nowhere at all depends on the receiving side's own filtering and your own sending reputation. Inbox placement is not something measurable from here, and nobody can promise it. See Email for the sending path and the four failure modes it publishes. [Email](https://customhosted.com/email) — Ours and yours
- The identity provider is down — A social-login or single-sign-on provider going down is an outage on their side, not something we can fix or route around. [Outside services](https://customhosted.com/outside-services) — Outside our control
- Everyone is logged out after a release — A single dedicated instance has no second copy standing by to take traffic while the new version starts. A release is a short, health-checked restart, not an instant handoff between two running copies. Storing the session outside the process, in the database, is the fix. [Deploys](https://customhosted.com/deploys) — Ours
- Someone is guessing passwords — Nowhere at the edge — a static site has no login to try. On a dedicated instance, this is your application's own job. [Under attack](https://customhosted.com/under-attack) — Yours

| Tier | What counts | Who hears, and when |
| --- | --- | --- |
| Auto-handled | A known, safe failure with an established fix — a crashed process, a failed health check, a stuck deploy | No one, unless it recurs — it goes in the log, not a message to you |
| You hear from us | Something that touched the app and needs a person to pick the right response, not just a retry | You, in writing, on the same quote channel as everything else — business hours for anything that isn’t urgent |
| Outage handling | The site or a core function is down, or badly degraded, for real users | You, as soon as there is something to say, with priority handling; out-of-hours response is best effort, not a staffed round-the-clock desk |

A login failure gets no special queue — it is watched and escalated the same way as any other failure. See [Monitoring](https://customhosted.com/monitoring) for the full ladder.

№ 07 This site's own login

## This site's own login: there isn't one

customhosted.com is itself a static site — the smallest possible case on this page, checked against the build.

- No session — customhosted.com is a static site. Nothing here keeps a visitor signed in, because nothing here can — the same fact § 04 states for any static plan.
- No stored password — There is no account to have a password for, and no store that could hold one.
- No admin screen — The only way to change this site is a pull request through the same pipeline as any other change — never a console reachable from the public address.
- One form, one relay — The quote form posts to a small managed endpoint that holds the one credential this site needs. It is a mail relay, not an identity provider.
- One disclosed cookie — The only cookie this site sets is the disclosed analytics one — see Privacy for the disclosure, and Performance for the third-party allowlist check that enforces it.

№ 08 What it costs

## What a login costs

No separate "login" line item — it rides on the shape and the tier a login actually needs.

- A login needs something that runs — A static plan cannot host a login of its own — a login means at minimum a Dedicated S plan, or a Custom quote for a shape Custom covers.
- A database tier for the session store — Keeping a session outside the running process starts at the DB Starter tier — see Databases for the full ladder.
- Wiring an existing login is a briefed change — Connecting a login your app already has to a new identity provider, or raising an attempt limit, is Agentic iteration — CodeHerder ($25/mo) work — the same pipeline as any other change.

№ 09 The CodeHerder line

## Wiring a login is a brief. Building one is a rebuild.

The line is drawn honestly, not softened to make a bigger sale.

Connecting a login your app already has to a new identity provider, adding a reset mail, or raising an attempt limit — each of those is a briefed change, opened as a pull request through the same pipeline as any other change:

1. 1 — A routine scan flags a dependency — The same kind of check that watches the infrastructure layers above, run against your application’s own dependency list. — CustomHosted
2. 2 — It's triaged as application-level, not infrastructure — A library your own code imports isn't ours to patch silently — it can change how the app behaves. — CustomHosted
3. 3 — Briefed as a change — Written up the same way any other change request is — this is what the Agentic iteration — CodeHerder add-on covers. — CustomLabs
4. 4 — An agent opens the pull request — The upgrade lands as a real pull request against the repository, with the test suite run against it. — CodeHerder
5. 5 — A human reviews and merges — Someone reads the diff before it goes anywhere near production — nothing here is auto-applied blind. — CustomLabs
6. 6 — It ships through the same pipeline — The same pipeline that deploys everything else on your stack ships this too — no separate process to babysit. — CustomHosted
7. 7 — You're told it's done — A note confirming what changed and that it merged, in the same shape as every other note on this site. — CustomHosted

Building authentication from scratch, or a new architecture around one, is not a brief — it's a rebuild, and belongs with CustomLabs.

№ 10 The honest limits

## Said plainly

No commitment published here without something behind it.

- A session held in memory does not survive a release — A single dedicated instance has no second copy standing by to take traffic while the new version starts. A release is a short, health-checked restart, not an instant handoff between two running copies. [Deploys](https://customhosted.com/deploys)
- We run no identity service — We do not run a login, single-sign-on, or social-login service on your behalf, and we do not set your app's cookie flags. Your application owns the login end to end; hosting only supplies what it stands on.
- We cannot recover a user's account — A forgotten password, a lost second factor, or a locked-out user is your application's own recovery flow to build. We hold no backdoor into any account your app protects.
- No sticky sessions — A single dedicated instance is the only copy of your app running, so there is no second copy to keep a signed-in visitor pinned to. "No autoscaling" is the rule underneath that — see Scaling for it in full. [Scaling](https://customhosted.com/scaling)
- Deliverability is never guaranteed — Whether a message lands in an inbox, a spam folder, or nowhere at all depends on the receiving side's own filtering and your own sending reputation. Inbox placement is not something measurable from here, and nobody can promise it. [Email](https://customhosted.com/email)

№ 11 Answers

## Logins, answered

The questions people ask once "just add a login" stops being the whole job.

1. 01 Do you provide a login system for my app? No. We host what your login runs on — a dedicated instance, and a database if the session lives there — but the login itself is your application's own code.
2. 02 Why did all my users get logged out after a deploy? A single dedicated instance has no second copy standing by to take traffic while the new version starts. A release is a short, health-checked restart, not an instant handoff between two running copies. Store the session in the database instead of the process's own memory and a release stops ending it.
3. 03 Can you set up single sign-on or social login for us? Wiring your app to an identity provider it already supports is a briefed change through the usual pipeline. Building the login from scratch, or a new architecture around it, is a rebuild and belongs with CustomLabs.
4. 04 Do clients get their own login? Not unless you want them to. By default you're the only account holder — a client gets the site, not a console to break. That question is about the hosting account, not about the login your own app presents to its users. This page owns the second one.
5. 05 A user forgot their password. Can you reset it for us? A forgotten password, a lost second factor, or a locked-out user is your application's own recovery flow to build. We hold no backdoor into any account your app protects. See Email for how the reset message itself gets sent once your app decides to send one.
6. 06 Does the platform stop someone guessing passwords against my login? Nowhere at the edge — a static site has no login to try. On a dedicated instance, this is your application's own job. A rate limit or lockout on a login endpoint is a briefed change, the same shape as the perimeter's other tie-in cases.

№ 12 Keep reading

## Logins connects to

- [Your data This site's own login — there isn't one — is the proof behind that page's worked artifact.](https://customhosted.com/your-data)
- [Access Who signs in to production — the other half of the picture this page never covers.](https://customhosted.com/access)
- [Under attack The perimeter, password guessing included — this page reuses its threat row and its attack-surface row whole.](https://customhosted.com/under-attack)
- [Email Delivery of a reset message once it reaches the relay, and the failure modes behind § 06's first row.](https://customhosted.com/email)
- [Configuration Where a secret — an identity provider's key included — actually lives.](https://customhosted.com/configuration)
- [Databases The store a session can sit in once it leaves the running process.](https://customhosted.com/databases)
- [Files The disk a session can sit on, and what an ephemeral filesystem means for one.](https://customhosted.com/files)
- [Deploys What a release actually does to a running instance — the mechanics behind § 05's memory row.](https://customhosted.com/deploys)
- [Outside services An identity provider is one of these — what changes when the far end breaks.](https://customhosted.com/outside-services)

## Wiring a login into a new provider, or raising an attempt limit?

Brief it through the same quote channel as any other request — Agentic iteration — CodeHerder ($25/mo) covers it.

[Get a quote →](https://customhosted.com/contact)