Deploy and Host Davis Calendars and Contacts on Railway

CalDAV and CardDAV with a protected administration dashboard.

Draft status: Configuration and upstream documentation reviewed. Container startup, Railway application workflows, restart behavior, backup restoration and costs remain unverified.

About Hosting

CalDAV and CardDAV with a protected administration dashboard.

Service	Role	Persistent path
`mariadb`	Private application or dependency	`/var/lib/mysql`
`davis`	Public application	`None`

Why Deploy

Run this application in your own Railway project, with explicit configuration and storage under your control.

Common Use Cases

Synchronize calendars through CalDAV.
Maintain contacts using standard CardDAV clients.

Dependencies for Davis Calendars and Contacts

Deployment Dependencies

The application images are pinned by registry digest. Database services, when included, stay on the private network. One replica is supported for each volume-backed service.

First use

Open the application HTTPS domain and follow the native authentication steps below.

Open the public application and log in as admin with davis.ADMIN_PASSWORD. Create regular DAV users in the dashboard; use those credentials for calendar/contact clients.

Scope and limitations

Unpublished draft; container startup, application workflows and recovery are not runtime-verified.
Uses native admin and DAV credentials instead of the owner gateway so standard DAV clients work.
WebDAV file storage and public calendars are disabled. Create ordinary calendar/contact users in the admin interface.

Acceptance checks before use

Verify the admin dashboard and DAV endpoint reject unauthenticated access.
Verify incorrect credentials are rejected, create a user, and sync a test event and contact with a DAV client.
Back up all persistent storage; restart and restore a copy before production use.
Confirm generated credentials are distinct on a second fresh deployment.
Back up every listed persistent path and database, then restore into a separate test project.
Measure Railway usage with representative data and workload before estimating operating costs.

Backups and upgrades

Back up databases, file volumes, encryption keys and configuration together. Keep a copy outside the running project. Review upstream migration notes before changing a digest; rollback can require restoring a compatible database and files, not just selecting an older image.

Sources and selection evidence

Upstream deployment documentation: Admin credentials, auth flags, database settings and migrations.
Upstream deployment documentation: Standalone image HTTP9000.
Upstream deployment documentation: Supervisor startup and Caddy/PHP deployment.
Upstream project

Product and alias searches found no matching public Railway listing during this research. This is a bounded search result; private, unindexed or differently named listings may exist. It is not evidence of demand or revenue.

Upstream software retains its own license and edition restrictions. This deployment draft does not imply upstream endorsement.