For your IT and security team

How it runs

• Erlangly is one Docker container on a Linux server you run: Ubuntu or Debian, on x86-64 or ARM64, in your cloud account, your data centre or your office. It's a Rails app with a compiled core for staffing, scheduling and the licence check, and its data is in SQLite databases in a Docker volume on that server. There's no separate database server or anything else to run beside it.
• Your planners, supervisors and agents use it in a browser, agents mostly on their phones. Your own scripts and AI assistants use its API.
• We, FrontLine Software Solutions, don't host it and can't reach it. We have no account on your install, no remote access and no way to sign in to it, and there's no telemetry.

What connects where

Coming in: the people who use it, on port 80, and 443 once it has a domain (or the one port your own HTTPS proxy forwards to). Going out, only these, and all but the first only once you set them up:

Any other ACD sends agents' states in, to /api/v1/agent_state_events, with its own token. AI assistants that run in a vendor's cloud (claude.ai, ChatGPT) can only reach an Erlangly that's on the internet.

Encryption

• In transit: give Erlangly a domain (TLS_DOMAIN) and it gets a Let's Encrypt certificate, serves HTTPS only, sends plain HTTP on to it and tells browsers to use HTTPS for two years (HSTS). Or put it behind your own HTTPS proxy (ERLANGLY_URL): Erlangly then sends HSTS and marks its cookies secure, and your proxy turns plain HTTP away, so only the proxy should reach Erlangly's port. Without either, it serves plain HTTP, which is only for a trusted network: admins opening Settings → System that way at a public address see a warning. Install with HTTPS.
• At rest: the databases are files on your server's disk, and Erlangly doesn't encrypt them itself. Use your server's disk encryption, or your cloud provider's encrypted volumes.
• Secrets: the mail server password, the single sign-on client secret and each ACD connection's secrets are encrypted in the database (AES-256-GCM), with a key made from your install's own secret key, which it generates on first start. Passwords are stored as bcrypt hashes. API tokens, AI assistants' tokens and ACD connection tokens are stored only as SHA-256 digests. The licence key is stored as it is, and the short-lived access keys your ACD gives Erlangly are kept unencrypted in its cache until they expire.
• Backups: backups and Litestream copies aren't encrypted by Erlangly, and a backup holds the install's secret key too, so whoever has one can read everything in it, the secrets included. Keep them as safe as the server: on encrypted storage, or in a private bucket with keys of its own, for only the people who run Erlangly.

Backups and recovery

• Every night Erlangly backs up all its data on the server, and keeps one a day for a week and one a week for the four weeks before (you can change how many). erlangly backup writes one to /var/backups/erlangly, readable only by root, to copy off the server with your usual backups.
• erlangly restore checks a backup before it puts it back, and a damaged one changes nothing.
• With Litestream, every change to the main database is copied to your bucket within seconds. A new server given your /etc/erlangly/erlangly.conf restores from it on its first start.
• Each upgrade takes a snapshot before it changes the database, and puts the previous version and the snapshot back by itself if the new version doesn't start.
• How much you could lose is up to what you set up: up to a day with nightly backups copied off the server, seconds with Litestream.
• Admins are told in Erlangly, and by email once email is set up, when a backup fails, the disk runs low or an ACD connection stops. /up?deep=1 lets your monitoring see it too. Running Erlangly.

Who can do what

• Four roles, each with everything the one before can do: agents see their own schedule and ask for time off and swaps; supervisors follow the floor and decide requests, never their own; planners forecast and schedule; admins also manage users, connections, sign-in, backups, exports and the licence. Users and roles.
• Passwords: at least 12 characters, 10 tries per account in 3 minutes, sessions of 30 days. A reset signs the person out everywhere and revokes their API tokens and AI assistants.
• Single sign-on: OpenID Connect with PKCE, with Microsoft Entra ID, Okta, Google Workspace or any OIDC provider. Require it for staff or for everyone, from the email domains you allow, with sessions of 12 hours. Break-glass admins keep a password, and once email is set up, each of their password sign-ins is emailed to the other admins. Turned off at your provider, someone can't sign in again once their 12 hours are up; their API tokens and AI assistants last up to 30 days, so turn them off in Erlangly too. Erlangly has no second factor of its own: require one at your provider. SAML and SCIM aren't there yet. Single sign-on.
• Leavers: turning someone's account off signs them out everywhere, and their tokens and AI assistants stop working.
• API tokens: personal, with their owner's role, read-only unless made to change things, and expiring after 30 days, 90 days or a year (30 days at most when SSO is required). They leave out other people's email addresses, ACD IDs and time-off notes unless an admin includes them. Shown once; admins see and revoke everyone's. API and command line.
• AI assistants (MCP): off until an admin turns them on. Each signs in as a person (OAuth with PKCE), reads only unless they chose otherwise, and can't publish a schedule. Its keys last an hour and are renewed while it's in use; it's disconnected after 30 days unused. It never sees other people's personal details. (Developer tools can use a personal API token instead, with that token's access.)
• Audit trail: who created or changed people, users, time off, swaps, shifts, schedules, forecasts and most settings, and when; every export; every API token and AI assistant. Nobody can change it in Erlangly, and admins get it with an export. Deletions aren't in it yet, and nor are ordinary sign-ins; break-glass ones are.
• Limits: 600 API requests a minute from one address, 300 a minute for each AI assistant, and request bodies of 10 MB (2 MB for the API).

Updates and security fixes

• Security fixes come in a new release; we don't patch older versions. erlangly upgrade installs it, and while the daily update check is on, admins see a note in Erlangly when one is out. The changelog says what each release changes.
• The erlangly command downloads each release by the image digest listed at get.erlangly.com/images, never just by its tag, and checks its own updates against published checksums.
• Labour-law rule packs are signed, and Erlangly checks the signature before it installs one. Licence keys are signed too, and checked on your server, offline.
• With a pay-once licence, upgrades install releases from before its Updates end. Once they've ended, newer releases, and the security fixes in them, need Updates again.
• Found a problem? Email security@erlangly.com: we reply within two business days (reporting a problem).

How we look for vulnerabilities

• Every change runs Brakeman (static analysis), bundler-audit against an up-to-date advisory database, cargo-audit for the compiled core's dependencies, and the full test suite, in a browser too, with a check of every page for every role.
• Every release's image is scanned with Trivy, and a fixable high or critical vulnerability fails the release, except a short list we've looked at, each with a date it must be looked at again.
• Each release is installed over the last public one on a fresh Ubuntu server and checked, and a release is made public only once all of these checks have passed.
• The container runs as an unprivileged user, and pages carry a strict Content-Security-Policy.
• Not yet: signed container images, a software bill of materials, or a third-party penetration test.

What we can't see

• Your people, schedules, forecasts, time off, ACD data or anything else in Erlangly: it never leaves your server for ours.
• Whether or how you use it: there's no telemetry, no error reporting to us, and the licence is checked offline.
• The daily update check, which, like any web request, shows us your server's IP address, and which you can turn off.
• Anything you choose to send us for support, which we use only to answer you (privacy policy).

What's yours to look after

• The server: its updates, its firewall (only the ports above open, and Docker opens published ports past ufw, so check from another machine), its disk encryption and who can sign in to it.
• HTTPS, with a domain or your own proxy.
• Copies of backups off the server, kept as safe as the server.
• Upgrading when releases come out.
• How people sign in: single sign-on and a second factor at your identity provider.
• The personal information you keep in Erlangly. Admins can export it all; Erlangly doesn't yet erase or anonymise a person, and keeps agents' states from your ACD for adherence.

Documents

• The security questionnaire, filled in (CSV, for a spreadsheet).
• Security: how it's built, and reporting a problem.
• Privacy policy, including who handles what for us.
• Licence agreement.
• Install and Running Erlangly.

Something we haven't answered? Write to support@erlangly.com.