Reconnecting…
Waiting for the connection. It is taking a while. Reload the page
This page hit a problem
It is reconnecting and will carry on from where it was.
Hosting
Alba Ticket is one piece of software that runs in two places: a workspace at your-team.albaticket.com that we operate, or an installation on machines you control. Every feature is in both, the price list treats them alike, and a workspace can be exported from one and imported into the other. What differs is who holds the data, who does the work of keeping it running, and what your data policy allows. This page goes through each in turn.
Choose it when you want a helpdesk this afternoon and nobody on the team whose job is servers. We create the workspace, run the database, the attachment storage and the search index, take the backups, apply the upgrades, deliver the email and keep the certificates current. You administer the workspace: people, projects, workflows, integrations. The data is yours: isolated from every other workspace in the database itself, exportable as one file at any time, and gone when you delete it.
Choose it when your policy says where tickets and attachments may live, when the names of the people who raise requests must never leave your network, or when you already run PostgreSQL and object storage and would rather add one container than one supplier. Nothing about your installation reaches us: not a ticket, not a name, not a usage count, not a licence check. The price of that is the work: you install it, back it up, upgrade it and watch it.
In both cases the data is yours. The difference is whether anyone else handles it on your behalf, and what you must take on trust rather than see for yourself. Everything below is stated in the terms and the privacy policy, which say the same things at greater length.
Hosted by us
You are the data controller of everything in the workspace. NordStack processes it only to provide the service, on the instructions you give through the service, and never reads, uses or discloses it for any purpose of its own. That is written into the terms and the privacy policy rather than left to a side agreement.Self-hosted
You are the controller and the processor both. NordStack is neither: the software sends nothing to us, and we cannot see, export or delete anything in it. The legal pages inside your installation say exactly that, naming your organisation as the operator.Hosted by us
In the database, object storage and search index we run, on infrastructure from providers who process data under contract and only to provide the service. Your workspace's rows are separated from every other workspace's in the database itself, by PostgreSQL row-level security, not only by the application; its attachments are in storage of its own and its search index is a collection of its own. The privacy policy says plainly that data may be held outside your own jurisdiction. If that is a problem for your policy, the answer is the other column.Self-hosted
Wherever you put it: a server in your own building, your own cloud account in the region your policy names, or a network with no route to the internet at all. Tickets and history are rows in your PostgreSQL, attachments are objects in your S3-compatible bucket, and the search index is your Typesense, rebuilt from the database whenever you like. The application makes no outbound connection you did not configure.Hosted by us
The people in your workspace, according to the roles, groups and per-ticket security levels you set. The people who operate the service can reach the systems it runs on, because somebody must, and are bound by the terms not to read, use or disclose what is in a workspace. Nobody else: nothing is measured inside a workspace, and no page loads a script, a font or an image from another company.Self-hosted
The people you let in, and whoever administers your servers, your database and your storage. Nobody outside your organisation, and that includes us.Hosted by us
The infrastructure, storage and email providers that the service runs on, under contract. Stripe, if you pay, is given who is paying and how many seats, never a ticket, and card details never reach our servers at all. No advertising, no third-party analytics inside a workspace, no trackers.Self-hosted
Only what you connect: your mail server, your identity provider for single sign-on, a code host whose issues you import or whose webhooks you accept. Pages load nothing from anyone else, the time-zone database is compiled in rather than fetched, and a licence key is verified on your own server with no call home.Hosted by us
One file, at any time. An administrator exports the whole workspace, attachments and history included, as a single archive in PostgreSQL's own JSON format, and can import it into any other installation or workspace. There is no lock-in to unwind and no request to make of us.Self-hosted
The same export, and the database itself: a plain PostgreSQL database that you can query, dump and back up with the tools you already have, and a bucket of files named by ticket.Hosted by us
An administrator deletes the workspace by typing its address. It closes at once, and shortly afterwards its rows, its attachment objects, its search index and any queued jobs are removed and the subscription cancelled. No copy is kept and we cannot restore it. What remains in routine backups is never restored into the service and disappears as those backups expire, which the privacy policy promises.Self-hosted
Stop the container and drop the database and the bucket. There is nothing anywhere else to ask about.A ticketing system is not finished when it is installed. It needs backing up, upgrading, watching and, now and then, rescuing. Hosted, that is what you pay us for. Self-hosted, it is what the licence costs less for.
Hosted by us
A form, a confirmation link and a button. The workspace is ready within a couple of minutes, at its own address, with a certificate already in place.Self-hosted
A server, the compose file and an afternoon; longer if you bring a managed database or run it on Kubernetes. There are guides for Docker Compose, Coolify, AWS and Azure.Hosted by us
Applied by us, as releases appear. Pages that are open reconnect and reload themselves; somebody in the middle of typing is shown a bar and reloads when ready.Self-hosted
Yours to apply: take a backup, set the new image tag, pull and restart. The migrations run before the new version starts, and if they fail the old version keeps running. The upgrade guide has the steps, and a licence includes the updates.Hosted by us
Taken by us, routinely, of the whole service, and kept for a short, fixed time. They are how we recover from a failure of ours, not a copy of your workspace held for you: the terms are explicit that the service is not a backup of your content, so export what you cannot afford to lose.Self-hosted
Yours: a scheduled database dump, a copy of the attachment bucket, and the two secrets in the environment file, without which stored credentials cannot be read. The backups guide gives the commands and a restore procedure. Daily dumps kept for a month are a reasonable default.Hosted by us
Run and rebuilt by us.Self-hosted
A Typesense service beside the application, in the bundled compose file. It holds derived data only and is rebuilt from the database from the administration pages, so it is never backed up. Without it, only exact ticket keys match in the search box.Hosted by us
Login links, invitations, notifications and the daily digest are delivered by us.Self-hosted
Your SMTP server. Without one, login links and invitations cannot be delivered, so this is the one service you cannot leave until later.Hosted by us
Storage is provisioned for the workspace when it is created. Files go straight from the browser to storage over signed links and never pass through an application server.Self-hosted
A bucket on S3, RustFS, Cloudflare R2, Backblaze B2 or anything else S3-compatible, with an access key and a CORS policy that lets browsers upload to it directly. The compose file bundles RustFS to start with.Hosted by us
Your workspace's address under ours, with TLS already in place.Self-hosted
Your reverse proxy, your domain and your certificate. The reverse proxy guide covers nginx, Caddy and Traefik; Caddy obtains certificates by itself.Hosted by us
Sized and watched by us. If one server is not enough, that is our problem to solve.Self-hosted
One node is enough to start. The nodes are stateless and cluster over Erlang distribution when one is not enough; see clustering. High availability for PostgreSQL, the object store and the mail server is arranged with those systems' own tooling, and is yours to arrange.Hosted by us
Ours, around the clock. You see a workspace; the machines are not your concern.Self-hosted
A health endpoint for your monitoring, logs to standard output, a system dashboard for administrators, and a troubleshooting guide for when something looks wrong. Someone on your side gets the page at three in the morning.Hosted by us
Ask us through the contact form, and we can see what the service is doing for your workspace.Self-hosted
The user and technical guides for everyone, and support with a licence. We cannot see your installation, so a question comes with your logs rather than ours.Less than most systems of its kind. The application is one container that does everything, background jobs included, so there is no separate worker, message broker or cache to run. What it needs beside it is what any serious application needs, and you may well have it already.
The bundled compose file runs all of it on one machine, with RustFS for attachments and a mail catcher for evaluation, so a first look needs nothing but Docker. For production, point it at the PostgreSQL, bucket and mail server you run, and put your reverse proxy in front.
Plan an afternoon for the first installation and a small routine afterwards: check that the backup ran, apply a release when one appears, and watch the disk, which attachments fill faster than tickets do.
Most of what protects your data is in the software, so it is the same in both. What differs is the perimeter: ours, or yours.
Single sign-on secrets, storage credentials, import tokens and webhook secrets are encrypted in the database with a key the application holds. A database dump alone does not give them up.
Files travel between the browser and storage over short-lived signed links. No application server ever holds their bytes, so there is one less place for them to leak from.
Project roles, groups and per-ticket security levels are applied in every query that returns a ticket, so a list, a board, a search result and a link all show the same person the same things.
OpenID Connect single sign-on per organisation, with registration that can be open, by invitation or through single sign-on only, so the accounts are the ones your directory says exist.
Every change to a ticket is recorded with who made it and what it was before. Deleted tickets are archived rather than erased and keys are never reused, so an audit trail does not need to be added on.
Every page carries a content security policy that allows scripts only from the application itself, and no font, image, script or stylesheet is loaded from another origin. Pasted content is rendered through a fixed allow-list, never as raw HTML.
Every table carries the workspace it belongs to, and PostgreSQL row-level security refuses a query from one workspace that reaches another, whatever the application asks. Each workspace's attachments are in storage of its own and its search index is a collection of its own, so isolation does not rest on one clever query being right.
The perimeter is yours: your firewall, your VPN, your network segment. Alba Ticket can run on a network with no route to the internet, and the only connections it makes are to the services you gave it. A workspace serving customers can sit on the public internet while the rest of your systems do not.
The price list has the numbers, in dollars and euros. The shape is the same in both: one product with everything in it, the helpdesk, time tracking, invoicing and the knowledge base included, charged per seat, where a seat is a member who has logged in during the last 30 days. The people who raise requests are never charged for, however many there are, and the same volume discount applies from the same number of members whichever way you run it.
Hosted, a workspace is billed monthly or yearly, after a 30-day trial that asks for no card. A workspace of up to 5 members, 2 projects and 2 GB of attachments is free for as long as it stays that size. Nothing is ever deleted for non-payment: a workspace that has outgrown the free plan and not chosen one becomes read-only after thirty days' notice, and everything in it can still be read and exported.
Self-hosted, an installation of up to 10 seats runs with no key at all, and a larger one buys a licence per seat, a year at a time, at a lower price than the hosted service because you provide the machines. A licence only ever shows a notice: an expired or over-limit key never stops the software, and renewing buys updates and support rather than the right to keep running what you have. Add to the licence what the servers and the hours cost you; for a team that already runs PostgreSQL and a bucket that is close to nothing, and for one that does not it is often the larger part.
Most organisations do not choose on taste. They have a policy, a regulator or a customer contract that answers the question for them. These are the clauses we are asked about most, and what each means here.
The choice is not permanent. A team that starts hosted to get going and is later told the data must come in-house exports the workspace and imports it into an installation of its own; a team that tires of running servers does the reverse. Every ticket, its history, its attachments, the workflows, boards, sprints, people and settings travel in one file, and the ids are kept, so links and references inside the data survive the move.
What does not travel is what should not: passwords, and the secrets of integrations and single sign-on, which are entered again on the other side. Reply links sent to people who used a public request form stop working, since they were signed by the installation that sent them.
Export
Administration, Export and import: one archive with everything, attachments included.
Create the other side
A new workspace with us, or a fresh installation from the guide, empty and at least as new as the one that made the export.
Import
The same page reads the archive in one transaction, so it is all there or none of it is, and running it again changes nothing.
Tell us what your policy says and what you run already, and we will tell you which fits, what running it yourself would take, and what the move from your current system would involve.