Deploy Zammad | (Just Updated) Zendesk Alternative No Stranger Can Claim First

Deploy and Host Zammad on Railway

Zammad is an open-source help desk and ticketing system — a self-hosted alternative to Zendesk and Freshdesk. Email, web forms and chat land in one shared inbox, become assignable tickets, and get routed, escalated and answered with SLAs, triggers, automations, a knowledge base and reporting. It ships importers for Zendesk, Freshdesk, Kayako and OTRS, so moving an existing help desk across is a supported path rather than a copy-paste job.

This deployment differs from a stock Zammad install in two ways that matter on a public URL.

The administrator account is created before anything binds a port. On a fresh Zammad instance POST /api/v1/users is served unauthenticated: UsersController#create falls through to create_admin, and Service::User::AddFirstAdmin only refuses once an admin already exists. So on a stock deploy the first stranger to reach the URL becomes Admin and Agent on your help desk, and the deployer is locked out of their own setup wizard. Measured on the stock image: two anonymous requests returned 201 {"message":"ok"}, then roles=Admin,Agent and a working login. Here the admin is seeded from ZAMMAD_ADMIN_PASSWORD during database init, so the first request the public port ever serves is against a configured system — the same call returns 422 This system has already been configured. The container refuses to boot on an empty password, and the password is re-seeded on every deploy, so rotating it is a redeploy rather than an impossibility.

Four Zammad roles run in one container, not seven billed services. The rails server, websocket server, background worker and nginx are the same image and share no volume — attachments live in Postgres — so this template is three services: Zammad, Postgres and Redis. Rails uses Zammad's own file cache store instead of a separate memcached, and Elasticsearch is off in favour of the built-in database search.

The Railway domain is also written into Zammad's fqdn and http_type settings at boot, so notification mail, password-reset links and callbacks point at the real instance instead of zammad.example.com — normally a manual post-deploy step in the admin UI.

About Hosting Zammad

Zammad is a Ruby on Rails application backed by PostgreSQL, with Redis behind the websocket session store that drives its real-time interface. First boot runs database creation, migrations and seeds before any process listens, which takes several minutes; later deploys run migrations only. There is no HTTP healthcheck on purpose — Railway's default healthcheck window is shorter than that first migration, and killing a Rails migration mid-flight is how a half-created schema happens.

nginx honours Railway's injected $PORT, and its resolver is written from the container's /etc/resolv.conf with IPv6 brackets, because Railway's private network is IPv6-only and the stock Zammad nginx config declares no resolver at all. Postgres keeps a volume mounted at the parent of its data directory. The upstream image is pinned by digest, since Zammad's migrations run forward only and an unrequested upgrade on redeploy is not a feature.

Common Use Cases

• Customer support shared inbox — turn a support address into tracked, assignable tickets with SLAs, triggers and automations
• Internal IT or HR help desk — request tracking with a self-service knowledge base
• Leaving a SaaS help desk — a data-private replacement for Zendesk or Freshdesk, with importers for the tickets you already have

Dependencies for Zammad Hosting

• PostgreSQL — the system of record for tickets, users, attachments and settings
• Redis — websocket session store for the real-time interface
• An email account with IMAP and SMTP access — optional, but it is how most teams feed the inbox

Deployment Dependencies

• Zammad source, AGPL-3.0
• Zammad documentation
• Railway image built for this template

After Deploying

1. Wait for the first deploy to finish. It migrates and seeds the database before serving, which takes a few minutes; the URL answers once that is done.
2. Log in with admin@example.com and the generated ZAMMAD_ADMIN_PASSWORD from the Zammad service's variables. Change the email and password in Manage → Users afterwards if you like; note that a redeploy re-seeds the password variable's value.
3. Connect a mailbox under Channels → Email over IMAP and SMTP to start turning email into tickets.
4. Invite your agents and review the SLA and trigger defaults before pointing real customers at it.

Public self-registration is off (ZAMMAD_ALLOW_SIGNUP=false); set it to true if you want customers to create their own accounts.

Why Deploy Zammad on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Zammad on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.