Deploy and Host Pocket ID on Railway

Run Pocket ID, a passkey-only OpenID Connect provider, with guarded first-owner setup and persistent SQLite. Pocket ID source is the main upstream product. Recipe 1.0.1 is published, using the immutable standalone recipe source. Its v1.0.1 tag and release-v1 branch resolve to that qualified revision; historical v1.0.0 remains unchanged. Release-source documents record the pre-live snapshot; this marketplace overview records the subsequent October 6 qualification and publication.

About Hosting Pocket ID

This recipe pins Pocket ID 2.17.0 and exact runtime APKs, with one service, one replica and one dedicated 1000 MB volume at /app/data. Its public gateway keeps application routes operator-only by default with GATE_FORCE_LOCK=true; the backend and actor listeners stay loopback-only. Owner setup is manual over the final verified HTTPS issuer, requires two separately verified credentials and explicit activation. Setting the force lock to false after activation exposes permitted login/application/OIDC routes; upstream authorization then enforces user privileges.

Marketplace description: Passkey OIDC identity with guarded setup and persistent SQLite.

Product icon: Pocket ID logo. This description, product icon and upstream links match the template metadata.

Why Deploy Pocket ID on Railway?

Railway supplies an HTTPS edge, service lifecycle and a persistent volume. The recipe adds a locked setup perimeter, independent encryption/operator secrets and recovery/restore instructions. A health check does not create an administrator or unlock the identity provider.

This is a small-team single-node baseline with no HA claim. October 6 qualification passed the exact queried stored Deploy V2 graph and frozen source, publicly trusted Railway HTTPS owner/member enrollment, positively authenticated non-admin denials, signed S256 OIDC grants and protocol negatives, enrolled native restart, and full hash-checked restore onto an independently empty replacement volume with the original issuer and secrets. Supported native CLI recovery after losing both owner authenticators, replacement enrollment, lost-key revocation and consumed-link denial also passed. Twelve restored owner/OIDC/locked-outsider cycles ran for 132.5 seconds with returned resource metrics; this bounded soak is not a capacity guarantee. Protocol checks with virtual authenticators do not establish physical hardware custody, and direct IaC apply/reapply is not qualified by marketplace lifecycle tests.

The stored template declares a 1000 MB mount. The separate native recovery exercise used a 5000 MB replacement allocated by Railway's volume-create default; it does not demonstrate a 1000 MB allocation for that recovery path or alter the stored template size.

Distribution is source-only recipe/instructions, not an OCI image publication. The finite October 6 review in ARTIFACT_REVIEW.md and SECURITY_REVIEW.md is accepted for the reviewed source recipe and default boundary: no concrete missing grant/notice or demonstrated default request-reachable unpatched advisory requiring a source-only hold was identified. Applicable upstream grants/notices remain required; complete artifact/transitive clearance and future binary distribution approval are not claimed. Optional SMTP, hardware custody, universal security guarantees and legal certification are outside this scope.

Common Use Cases

Add passkey sign-in to OIDC-capable internal applications.
Replace application-specific passwords with authenticator-backed login.
Maintain a small team's self-hosted issuer with guarded owner setup.

Dependencies for Pocket ID Hosting

A stable final HTTPS origin and two independently usable owner credentials; operators manage their production authenticators.
One dedicated Railway volume, complete off-host backups and separately protected original encryption key.
Access to the published GitHub source/release channel through the Railway GitHub App; the qualified v1.0.1 source is linked above.
Private operator access to GATE_ADMIN_TOKEN and a separate Pocket ID administrator session.
Retention of required license notices and the accepted finite source-only review's documented boundaries; operators must qualify their own configuration and recovery procedures.

Deployment Dependencies

Follow README.md and PUBLISHING.md: set APP_URL before enrollment, keep the default lock during setup, and use /_operator at verified HTTPS. Do not expose the backend or substitute a static API key for setup protection. No SMTP account or remote database is required.

Qualification resources were standard-deleted after all 18 owned revisions showed zero active/running compute; the disposable SSH registration, local credentials and backup were retired. Retained volume rows included scheduled October 8 deletion. This satisfies the owner's accepted cleanup boundary, not proof of immediate physical erasure or billing-zero; platform logs/backups/records may remain.