Rallly: self-hosted group scheduling polls with Docker and Postgres

The back-and-forth Rallly removes, and who feels it most

The problem is narrow and familiar. Someone needs a time that works for five or twelve people, so they send a message asking when everyone is free, and the thread turns into a negotiation. Rallly replaces that thread with a poll: you propose a set of date and time options, share one link, and participants mark which ones they can attend. The README describes the same flow in one line, "Create a poll with a few options, share the link, and let your participants vote on when they're available."

The audience is the person who always ends up organising: a team lead booking a recurring sync, a club secretary, a lecturer arranging office hours, a volunteer coordinator. It is also for the participant, who is the more interesting case. The README states that no account is needed to vote, so the cost of responding is one click on a link. That single design decision is what separates a tool people actually fill in from one they ignore.

What Rallly is not is a calendar. There is no mention in the README of reading your existing availability, syncing to Google Calendar or Outlook, or booking a slot that then appears in anyone's calendar. It is a decision tool for a group, not a personal scheduling assistant. If you want the latter, you are looking at the wrong category.

How the poll, the vote and the finalised date fit together

The repository is a pnpm workspace driven by Turborepo, with the web application under apps/ and shared code under packages/. The stack named in the README and the topic list is consistent: Next.js for the app, Prisma against PostgreSQL for persistence, tRPC for the typed API layer, TailwindCSS for styling, next-auth for authentication, react-email for outbound mail, i18next for translation, and Zod for validation.

Data flow follows that shape. A poll is created through the web app, which writes it via Prisma to Postgres. The shareable link resolves to a page that renders the poll and its options. A participant's response is another write through the same path, and the availability grid is a read that aggregates those responses. Comments attach to the poll. When the organiser finalises a date, the README describes notifying everyone, which is where react-email comes in: mail is rendered from templates rather than assembled as strings.

The workspace split matters for anyone planning to modify it. The database layer lives in its own package with its own Prisma scripts, which is why the root package.json exposes commands such as db:deploy and db:migrate that delegate to @rallly/database. Migrations are therefore managed in one place rather than scattered across applications. There is also a separate landing package and a docs package, so a change to marketing copy does not require rebuilding the app.

Self-hosting Rallly with Docker Compose and Postgres

The README points self-hosters at the docs rather than reproducing the steps, and it says Rallly "ships as a Docker image". The repository ships a docker-compose.yml that is the clearest description of the intended deployment: a Postgres service and the application service, with the app waiting on the database health check.

The database service runs postgres:18-alpine, publishes host port 5450 mapped to container port 5432, and creates a database named rallly with the password postgres. The application service builds from ./apps/web/Dockerfile with the build argument SELF_HOSTED=true, publishes port 3000, and reads an optional env file at apps/web/.env.

services:
  rallly_db:
    image: postgres:18-alpine
    ports:
      - "5450:5432"
    environment:
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_DB=rallly

The application service receives its connection string directly in the compose file, and that variable name is the one to change if you point Rallly at a managed database instead of the bundled container.

  rallly_selfhosted:
    ports:
      - 3000:3000
    environment:
      - DATABASE_URL=postgres://postgres:postgres@rallly_db/rallly

Bring the stack up with the compose file in the repository root. The README does not document this command itself; the file is what defines the services, and the compose file is the source for the service names above.

docker compose up -d --wait

Once the containers report healthy, the app answers on port 3000. Your first real use is the product's core loop: open the app, create a poll, add a few date and time options, copy the share link, and open that link in a private window to confirm a participant can respond without signing in. If the poll page renders and the response lands in the availability grid, the database write path is working end to end. The README does not document a first-run admin account, so check the configuration options page for how the initial account is established before you expose the instance.

Where Rallly stops short

The most consequential limitation is not a bug, it is scope. Rallly decides a time; it does not put that time anywhere. There is no calendar integration in the README's feature list, no availability import, no recurring meeting support, no automatic reminders, and no booking page where an outsider picks a slot from your open hours. Tools in the adjacent category do those things, and if your workflow depends on any of them, Rallly will leave a manual step at the end of every poll.

Self-hosting carries its own failure modes. The compose file in the repository uses the password postgres and publishes the database on host port 5450. That is fine on a laptop and unacceptable on a public host, so the database should not be reachable from outside the container network in any real deployment. Outbound email is the other quiet dependency: notifications and finalisation messages are part of the feature set, and the README does not explain what happens to them when no mail transport is configured. Assume they are silently dropped until you configure one.

The licence is a genuine constraint rather than a footnote. Rallly is AGPL-3.0, which reaches network use: if you modify it and let other people interact with it over a network, the licence's terms apply to that deployment. For an internal instance running unmodified, this changes little. For a company that wants to fork the interface, add proprietary features, and offer the result as a service, it is a different conversation, and one for a lawyer rather than a review.

Rallly against Doodle and the wider scheduling field

The comparison people reach for is Doodle, and the difference is ownership rather than features. Doodle is a hosted service; you get an account, a poll, and someone else's infrastructure, and the free tier carries advertising and limits. Rallly's hosted version at rallly.co is the same shape, but the repository also gives you the entire application to run yourself.

That changes three things. Your poll data, including who said they were available when, sits in your own Postgres rather than a vendor's. The feature set is the one in the repository at the commit you deploy, not one that can be repriced or pared back under you. And you can change the code, subject to the AGPL-3.0 terms. The cost is that you now operate a web application and a database, handle backups, and keep up with releases.

Against calendar-native tools such as Calendly, the distinction is the unit of work. Calendly assumes you own the calendar and the other person picks from your free slots. Rallly assumes nobody owns the schedule and the group negotiates. Those are different problems, and picking the wrong one produces a tool that fights your workflow. If the honest answer to "when are you free?" is a list of slots you control, Rallly is not the fit.

Maintenance, releases and what the licence asks of you

Rallly is not abandoned. The last push to the main branch was on 2026-09-22, and the most recent release listed is v4.15.2 on 2026-09-21, following v4.15.1 on 2026-09-13 and v4.15.0 on 2026-09-09. That cadence suggests a project that ships fixes quickly, and it also means a self-hosted instance drifts out of date if you do not track it.

Upgrading a self-hosted instance is a database migration problem, not a container problem. The root package.json exposes db:deploy, which runs prisma migrate deploy against the @rallly/database package, and db:migrate, which runs prisma migrate dev. The first is the production path; the second is for development and can prompt to reset. Because the application and its schema move together, the practical rule is to pull the new image and run the deploy migration as one step, and to take a database dump before either.

On licensing, the README states Rallly is open-source under the GNU Affero General Public License Version 3 or any later version, and the repository carries the AGPL-3.0 identifier. The practical reading for an engineering team is that running an unmodified instance internally is unremarkable, while modifying the code and exposing it to users over a network brings the licence's source-availability terms into play. I am not a lawyer and this is not legal advice; if you plan to build a product on a fork, get the licence reviewed before you write the first line.

Editorial conclusion

Adopt Rallly if you want a scheduling poll you control and you are comfortable with the AGPL-3.0 obligations that come with running a modified copy as a network service. Skip it if you need calendar sync, availability import or booking pages with reminders, since the README lists none of those. Before committing, decide which database you will point DATABASE_URL at, and read the self-hosting configuration options page to see which environment variables the image expects beyond that one.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. lukevella/rallly on GitHub
3. Project website
4. README
5. Releases