Presentator: self-hosted design feedback and presentations

Presentator's feedback and presentation workflow

Presentator addresses a specific gap between uploading finished screens and discussing them in a separate chat channel. A user can publish presentation screens, place feedback directly on visual areas, attach comments, and manage participation through the platform. The repository includes API files for comments, hotspot templates, hotspots, links, notifications, projects, prototypes, screens, sharing, reports and user preferences. Based on those components, feedback is organized around project and presentation objects rather than being limited to a flat collection of uploaded images.

The presentation audience is primarily designers, product teams, reviewers and people who need to inspect proposed interfaces or prototypes. Presentator describes itself as both a design feedback and presentation platform. That combination matters when a team wants stakeholders to open a presentation, navigate screens and leave feedback without moving the discussion into email or a separate meeting transcript.

The repository is primarily implemented in Go, with the module named `github.com/presentator/presentator/v3`. Its `ui/` directory contains the interface code, while the primary language listed for the repository is SCSS. The server depends on Pocketbase, which supplies the application data layer, collections, authentication and administrative dashboard. This is not a client-only viewer or a static slide export. It is an application with user accounts, stored files, collections and configurable delivery settings.

A hosted version is available at `app.presentator.io`, while the same product can be run on a server through a single executable. Teams do not have to choose permanently between the hosted service and self-hosting at the outset, although the project documentation does not describe a migration procedure for moving an existing hosted account into a self-hosted Pocketbase database.

Presentator's Pocketbase-backed architecture

The clearest architectural clue is the documented `pb_data` directory. By default, Presentator stores settings and database data beside the executable in `pb_data`. The super-admin interface is the Pocketbase dashboard at `/_/`, while the normal application is served at `/`. This creates one operational directory containing persistent state, but it also means that operators must treat that directory as part of backups and deployment planning.

The `go.mod` file requires Pocketbase `v0.40.5`, along with Go database, validation and synchronization packages. Presentator-specific Go files extend that foundation. Names such as `hooks.go`, `migrations.go` and the files under `migrations/` indicate application hooks, mail handling and schema evolution within the Pocketbase environment. Repository tests for projects, screens, prototypes, hotspots, comments, reports, shares and users show that these are distinct server-side areas rather than merely static frontend views.

Feedback appears to use a hotspot model. The repository includes hotspot and hotspot-template API tests, as well as a dedicated `hotspot_settings.go` file. Links also have separate API tests, which is consistent with presentations that can combine visual annotations with navigable destinations. The documentation excerpt does not describe the precise coordinate format, collaboration rules or editing sequence for hotspots, so those details should not be inferred beyond the confirmed presence of screens, hotspot templates and hotspot handling.

File storage is also delegated through Pocketbase settings. Presentator uses the local filesystem by default, while an S3-compatible option is available for environments with limited disk space or substantial upload volume. SMTP, OAuth2 and storage are therefore operator concerns, not merely application preferences. This arrangement lowers the number of separate services required for basic deployment, although it places responsibility for schema safety and backup procedures on the administrator.

Installing Presentator and creating the first account

The documented local installation starts with a prebuilt executable from the GitHub Releases page. Choose the archive that matches the local machine, extract the Presentator executable, and open a terminal in its directory. Then start the server:

./presentator serve

Presentator binds its local interface to port 8090. The super-admin page is available at `http://127.0.0.1:8090/_/`. On the first launch, the application prompts for creation of a Pocketbase super-admin account. Expect the browser to open or allow access to that dashboard, where the operator can inspect collections and configure application settings.

After creating the super-admin account, open the application itself:

http://127.0.0.1:8090/

A first user can be created from the Pocketbase dashboard or registered through the normal application page. The local default is appropriate for evaluating the application, but it does not by itself describe production HTTPS, DNS or process supervision. Keep the `pb_data` directory with the executable because it contains the default database and settings.

The server also exposes command help, which is the correct place to inspect options that are not included in the README excerpt:

./presentator --help

This first-use sequence ends with an account, not a populated presentation. The README does not document the exact clicks or API calls required to create a project, upload the first screen or attach a hotspot, so the install should be treated as complete only after those application-specific creation steps are verified against the interface.

SMTP, OAuth2 and file storage configuration

Email is optional until Presentator needs to send messages, but it is central to operations involving invitations, account flows or notifications. SMTP configuration belongs in `Pocketbase Dashboard > Settings > Mail settings`. The application URL must also be updated under `Settings > Application`. The README names Mailjet, MailerSend, Brevo, SendGrid and AWS SES as possible external services, but it does not prescribe one provider or a universal set of credentials.

OAuth2 configuration is more delicate because it requires changing the `users` auth collection. Operators temporarily enable collection create and edit controls, open the `users` collection options, select the permitted providers, and then re-enable the hidden controls. Google, Microsoft, Facebook, GitHub and Gitlab are listed as examples. The callback path is explicit:

https://yourdomain.com/api/oauth2-redirect

A practical failure mode is provider mismatch. Presentator requires users to have an email by default, so a provider that does not return an email can fail authentication. Another deployment error is using localhost in the OAuth2 callback or application URL after moving the application to a domain. Both can occur because configuration is retained in the database rather than being determined solely by the executable command.

Uploaded screen images are limited to approximately 7 MB by default. Larger images require a deliberate change to the `screens` collection's file field. S3-compatible storage can replace local file storage through Pocketbase's file settings. Presentator does not document automatic migration between local storage and S3, so changing the storage backend should not be assumed to copy existing files.

Production deployment and operational constraints

The production instructions treat Presentator as a Pocketbase application. The documented minimal Linux layout keeps `pb_data/` beside `presentator`. An administrator can transfer that directory to a remote server with `rsync`, open an SSH session and start the executable with a domain argument. Supplying the domain allows Presentator to bind ports 80 and 443 and automatically issue a Let's Encrypt certificate.

rsync -avz -e ssh /local/path/to/presentatordir/ root@YOUR_SERVER_IP:/root/pr
ssh root@YOUR_SERVER_IP
/root/pr/presentator serve yourdomain.com

This is a compact deployment model, but the shown commands assume root access, an appropriate DNS setup and a compatible server architecture. A production operator would also need to follow Pocketbase's production deployment guidance, which the README links as the authoritative deployment reference. The README excerpt begins a Systemd example but does not include the complete unit file, so inventing the missing fields would be misleading.

The application also has a clear extensibility boundary. Server behavior can be extended through the Go codebase, migrations and hooks, while Pocketbase handles collections and dashboard administration. The README does not document a plugin API, a stable extension contract or a rollback procedure for migrations. That omission matters when upgrading an established installation. Database backups and release-specific migration notes should be checked before replacing the executable.

Presentator's maintenance, licensing and upgrade trade-offs

The repository is not archived, and its last push was on 2026-10-08. Recent listed releases include `v3.4.70` on 2026-10-08, `v3.4.69` on 2026-09-12 and `v3.4.68` on 2026-09-06. These dates establish recent project activity, but they do not establish compatibility, release stability or the presence of a documented upgrade path for every deployment.

Presentator uses the BSD-3-Clause license. That license permits use and modification under its stated conditions, while preserving the license and copyright notices. This is a source-code licensing statement, not legal advice. Teams still need to review the repository's `LICENSE.md` and account for the licenses of dependencies when distributing a modified deployment.

The upgrade cost is tied to the executable and the `pb_data` directory. Because the application is a Go binary with migrations and Pocketbase collections, an administrator must coordinate the binary version with the persisted database schema. The README links to Pocketbase production guidance and lists an updating section, but the supplied excerpt does not document rollback, migration compatibility or a backup command. That is a meaningful limitation for production adoption. It is also why a clean staging copy of `pb_data` is more useful than relying only on a newly downloaded release binary.

Compared with a hosted design review product, self-hosted Presentator gives the operator direct control over the server and database but transfers SMTP, OAuth2, storage, certificate, backup and upgrade responsibilities inward. Compared with a generic file-sharing page, its project, screen, hotspot, comment and presentation APIs provide a more structured review model. The trade-off is operational ownership.

Editorial conclusion

Presentator fits teams that need a private place to publish design screens, gather contextual comments and present prototypes, especially when one executable and a Pocketbase data directory simplify deployment. It is less suitable for organizations requiring documented white-label controls, unusually large uploads without schema changes, or a platform with no Pocketbase administration involved. Before adoption, verify the exact presentation workflow against your needs, test the OAuth2 and SMTP settings used in production, and confirm that your server architecture matches the downloaded executable.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. presentator/presentator on GitHub
3. Project website
4. README
5. Releases