Claper turns a slide deck into a live poll audience can join

An audience that can answer, not just watch

Claper is described as the ultimate tool to interact with your audience, and the project's own framing is that it turns your presentations into an interactive experience. The topics give the range: audience engagement, interaction, live, poll, powerpoint, presentation and public speaking.

The README states a two sided mission, and it is the clearest statement of intent in the project. The first side is helping people who present an idea or a message by giving them the opportunity to make their presentation unique and to have real-time feedback from their audience. The second side is helping each participant to take their place, to be an actor in the presentation and in the meeting, and to feel important and useful.

That second half is the interesting design constraint. A tool where the presenter sees the answers and the audience sees nothing but a poll link is a broadcast tool. A tool where the audience is supposed to feel like a participant needs the answering side to be fast, obvious and low friction, which is a different problem from the presenter side.

The project is built with Phoenix and Elixir, with Tailwind for the front end, and it is licensed under AGPL-3.0 with the licence text in LICENSE.txt. The homepage is claper.co and the documentation is at docs.claper.co.

Eight languages, and a hosted service you can use without deploying

The supported languages are listed as English, French, German, Spanish, Dutch, Italian, Hungarian and Latvian, and the site itself is linked from the README as the product screenshot.

The hosted service is the fastest route to using it. The README points to claper.co as where the product lives, and the documentation site at docs.claper.co is where the instructions and configuration live. For a speaker who wants polls in a meeting tomorrow, the hosted path means no server, no database and no upgrade cycle.

That hosted option is also what makes the repository interesting to read, because the self hosted path is a complete one. The compose file defines a database and an application, the Dockerfile builds a release, and the environment sample lists the settings. Everything needed to run your own instance is in the tree.

The repository layout follows a normal Phoenix application: lib, config, priv, assets, test, rel for the release configuration, plus a Dockerfile and a Dockerfile.dev for the development image, a compose.dev.yml, a charts directory, a build.sh, and with_env.sh for running commands with the environment loaded. There is a .tool-versions file, a .formatter.exs and a .credo.exs, so the project pins its toolchain and formats and lints its own code.

The compose file wires a database and an application

The deployment is two services on a private network. The database is postgres:15 with a named volume for the data directory, a healthcheck that runs pg_isready against the claper database and user, and three retries with a five second timeout. The application runs the published image ghcr.io/claperco/claper:latest, or it can be built from the local source with build: ., and it maps port 4000 to the host.

The application service also has a healthcheck, and it is a curl against the local port:

    healthcheck:
      test: curl --fail http://localhost:4000 || exit 1
      retries: 3
      start_period: 20s
      timeout: 5s

The start period of twenty seconds is there because the app is not expected to answer immediately after the container starts, which matters for a healthcheck that would otherwise restart a container that is merely warming up.

Two named volumes are declared, one for the database and one for uploads, and the uploads volume is mounted at /app/uploads in the app service. That mount is the local storage mode, and it is the point where the storage configuration becomes visible in the deployment rather than only in the environment file. The app declares a dependency on the database with the service_healthy condition, so the database is up and answering before the app starts.

Storage, mail and the secret you must change

The environment sample is where the configuration options are visible, and it is organised into sections that map onto the parts of the system.

The Phoenix section has BASE_URL, DATABASE_URL and SECRET_KEY_BASE, with the cookie settings commented out. The secret key carries an explicit warning that the exact value in the file must not be used, because someone would be able to sign a cookie with user_id=1 and log in as the admin. The comment even gives the command to generate a proper one, mix phx.gen.secret. That warning is the single most important line in the file for a self hosted deployment.

The storage section has PRESENTATION_STORAGE set to local with a directory of /app/uploads, and a commented MAX_FILE_SIZE_MB. The standard AWS variables are all there for S3, including an S3_PUBLIC_URL for the case where the public URL differs from the one used to write the data, and a set of optional scheme, host and port settings for S3-compatible services that are not AWS.

The mail section chooses the transport, with local as the default and smtp and postmark as the alternatives, and each alternative has its own block of settings. There is also a dev mailbox option with a route flag, a user and a password.

The final section is the Claper configuration, with account creation, email confirmation and unlinking external providers as toggles, and a logout redirect URL.

The release build compiles a Phoenix release on Ubuntu

The Dockerfile shows how a Phoenix application becomes a container image, and the ordering in it is the interesting part.

The builder is the official Elixir image at version 1.18.4 with Erlang 28.0.1 on Ubuntu Noble, and it installs the usual build tools plus nodejs, npm, openssl and libncurses5-dev. The environment sets the node version to 22.17.0 and the presentation storage directory. There is a custom ERL_FLAGS argument, with a comment explaining that it is passed for public multi-platform builds to work around a qemu segfault, with a link to the Erlang pull request.

The build sequence copies mix.exs and mix.lock first, installs only the production dependencies, then creates the config directory and copies the compile-time config, so that a change to configuration triggers a recompile of the dependencies. Only after that does it copy priv, assets and lib, compile, run the asset deployment task, copy the runtime config and the release directory, and finally run mix release.

The second stage is a plain ubuntu:24.04 runner with curl, libstdc++6, openssl, locales, ghostscript, imagemagick, a default JRE, libreoffice-java-common and libreoffice itself. Ghostscript, ImageMagick and LibreOffice are there for a reason: converting and rendering uploaded presentations is not a job the Elixir runtime does on its own.

A live product with a public changelog and an active branch

The release history shows a project that ships often. v3.1.1 was tagged on 2026-10-15, v3.1.0 on 2026-10-02, and v3.0.0 on 2026-08-06. That is a major version in the summer followed by two minor releases, which is the pattern of a product that reorganised something in the 3.0 line and then iterated on it.

The repository is not archived and the last push was recent, shortly after the newest tag, so the branch and the release are in step. The default branch is dev rather than master, which is worth knowing before you open a pull request, since the contributing steps in the README say to open the pull request against the dev branch.

The contributing flow itself is spelled out: fork the project, create a feature branch, commit the changes, push the branch and open a pull request on dev. Issues can be opened with the tag enhancement.

There is a CHANGELOG.md, a CONTRIBUTING.md, an AGENTS.md, a Discord server and a subreddit linked from the README. The AGPL-3.0 licence covers the code; if you plan to run a modified copy as a service, that licence reaches your modifications, and any specific compliance question belongs with your own counsel rather than with this page.

Editorial conclusion

Claper suits a speaker or a training team who wants real feedback from a room rather than a webinar chat full of silence, because the tool pairs a presentation with a poll surface the audience opens on their own device. It is the wrong choice if you need a full content management system for slides or a heavyweight analytics suite, since the scope is the interaction layer. Before deploying it yourself, replace SECRET_KEY_BASE as the sample file warns, decide between local and S3 storage for presentations, and read the documentation at docs.claper.co for the configuration options the README defers to.

Frequently asked questions

Official sources

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