The people who sign in to your app
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.
"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
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
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.
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
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
CustomHosted
- 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
You
- 3
Outbound mail for a reset
A password-reset message rides the same outbound path as any other mail your app sends. Email
You
- 4
A secret for an identity provider
An API key, a database password, a signing key, a connection string. Configuration
You
- 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
You
- 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
You
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.
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. |
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
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
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
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
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 for the full ladder.
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.
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.
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
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
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
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
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
A human reviews and merges
Someone reads the diff before it goes anywhere near production — nothing here is auto-applied blind.
CustomLabs
- 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
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.
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
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
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
Logins, answered
The questions people ask once "just add a login" stops being the whole job.
01Do 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.
02Why 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.
03Can 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.
04Do 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.
05A 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.
06Does 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.
Logins connects to
- Your data
This site's own login — there isn't one — is the proof behind that page's worked artifact.
- Access
Who signs in to production — the other half of the picture this page never covers.
- Under attack
The perimeter, password guessing included — this page reuses its threat row and its attack-surface row whole.
- Email
Delivery of a reset message once it reaches the relay, and the failure modes behind § 06's first row.
- Configuration
Where a secret — an identity provider's key included — actually lives.
- Databases
The store a session can sit in once it leaves the running process.
- Files
The disk a session can sit on, and what an ephemeral filesystem means for one.
- Deploys
What a release actually does to a running instance — the mechanics behind § 05's memory row.
- Outside services
An identity provider is one of these — what changes when the far end breaks.
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.