Reactive Resume v5.2.7: who should self-host it and what to check before upgrading


In brief: Reactive Resume is a capable, actively developed resume builder that its maintainers describe as free, open-source, and self-hostable. For an operator, the question is whether you are ready to own a Docker-plus-PostgreSQL application that changes quickly. For a small team that already runs containers and can maintain backups and upgrades, it is a reasonable fit. For anyone looking for an install-once resume tool with guaranteed rendering or commercial support, it is not the right tool. This article is a source and documentation review as of 2026-08-21 based on repository, release, and issue metadata; no local installation or runtime testing was performed.

Key facts at a glance

Item Snapshot
Review date 2026-08-21
Repository amruthpillai/reactive-resume (created March 2020)
License MIT
Stars 41,337 (snapshot)
Forks / open issues 4,638 / 108 (snapshot)
Language TypeScript
Latest release v5.2.7, published 2026-08-17
Verification level Observed – source and documentation review

What this review is based on

Everything below comes from the public repository page, README, v5.2.x release notes, and open issue reports as captured on 2026-08-21. Claims about features, architecture, and maintenance workflow are the maintainers’ claims; nothing here is a tested or benchmarked result. Stars, forks, and issue counts are snapshots, not trend guarantees.

What v5.2.7 changes for operators

The v5.2.7 release notes describe the main changes:

  • Custom Styles now compile in the browser. The server no longer runs a stylesheet preflight worker on every edit, and the maintainers expect lower memory and CPU use on instances where Custom Styles are active. Server-side PDF generation stays available as a fallback when a browser cannot render locally.
  • Shared resume links now unfurl with a preview card. The release notes also say the homepage’s own card and structured data reach crawlers again, because the static file handler had been answering the root request before the code that injects them could run.
  • The AI agent asks when a request is ambiguous instead of guessing at an interpretation.
  • Job-application auto-fill now works from pasted posting text instead of a URL. The maintainers removed server-side URL fetching, citing redirect, size, and private-address defenses plus per-site scraping quirks.
  • The page formerly called Danger Zone is now Account; API keys without an expiry date are listed again; and AI provider connection tests are time-bounded and report a failure reason.
  • Test suites were isolated, a Windows conflict-marker check was fixed, and issue triage was reorganized.

Two upgrade facts matter beyond this release. From v5.1.0 onward, PDF generation runs client-side with @react-pdf/renderer, so new deployments no longer require Browserless or Chromium, and the PRINTER_* and BROWSERLESS_* environment variables are no longer read and can be removed. In v5.2.6, MCP OAuth JWT verification was changed to use the server’s loopback JWKS endpoint, fixing deployments whose public URL cannot be reached from inside the container.

Who should consider Reactive Resume

Reactive Resume is aimed at people who want a resume builder without handing their data to a hosted service. The README emphasizes privacy, full data export, one-click deletion, no tracking or ads, and self-hosting. The feature set (templates, PDF/JSON/DOCX export, JSON Resume import, multi-language support, passkeys and two-factor authentication, and optional AI integrations) fits these groups:

  • Founders or small businesses that want to offer resume-building as a service or internal tool and keep user data under their own control;
  • Teams with someone comfortable running Docker Compose, PostgreSQL, and a reverse proxy, since that is the practical support baseline;
  • Developers who want a modern TypeScript and React codebase to customize or extend;
  • Organizations that already run self-hosted software and can absorb a fast release cadence: v5.2.3 through v5.2.7 were published between July 8 and August 17, 2026.

Who should be cautious

  • Non-technical users without operations support: the Docker and PostgreSQL setup is not a managed product, and there is no commercial support or SLA.
  • Teams with strict PDF and layout requirements: several rendering issues remain open, including a confirmed font misalignment issue that also occurs on self-hosted instances and a confirmed skill-icon overflow problem reported on self-hosted 5.1.2 and 5.1.5.
  • Teams planning heavy reliance on AI features: open issues report a custom base URL returning Not Found (confirmed), an AI import failing with Bad Gateway on the hosted service, and connection tests succeeding while enabling AI still fails.
  • Heavy users of the previous Custom CSS: one open enhancement request describes the newer Custom Styles as a regression that no longer allows deep modification of templated areas such as the header.

Deployment and upgrade concerns

The README’s quick start is a single docker compose up -d with the web app on port 3000. The stack includes PostgreSQL with Drizzle ORM, and SeaweedFS is optional S3-compatible storage for file uploads. Images are published to Docker Hub and GitHub Container Registry. Before production, operators should check at least these points:

  • Backups and restore testing for PostgreSQL, because resume data lives in the database;
  • Where uploaded files are stored and whether the optional SeaweedFS or S3-compatible service is needed;
  • HTTPS, reverse proxy, and whether the public URL is reachable from inside the container (a problem class the maintainers addressed for MCP OAuth in v5.2.6);
  • Removing obsolete PRINTER_* and BROWSERLESS_* variables when upgrading from pre-v5.1.0 deployments;
  • AI provider keys, model names, and custom base URLs, since provider configuration is a reported source of failure;
  • Verifying PDF export in the browsers your users actually use, since v5.1.0 moved PDF generation client-side.

Maintenance signals

The project shows active maintenance: the repository was pushed on 2026-08-20, five v5.2.x releases were published between July 8 and August 17, 2026, and the README describes a weekly triage workflow for the status: needs triage queue, with triaged bugs marked confirmed and feature proposals marked accepted. At the review snapshot the repository had 41,337 stars and 4,638 forks, which indicates community attention rather than a quality guarantee. There were 108 open issues, several of them confirmed rendering bugs and AI integration failures, so operators should not assume the backlog is clear.

Limitations and open issues

The most important limitations are not missing features; they are where the project currently has known, open defects:

  • Rendering: confirmed font vertical-alignment issues (#3249), skill-icon overflow on self-hosted instances (#3040), and reports of overlapping characters, missing profile pictures, and a broken center preview on the hosted service (#3106, #3168, #3007).
  • AI integrations: custom OpenAI-compatible base URLs can return Not Found (#2805, confirmed); hosted AI resume import can fail with Bad Gateway after a successful connection test (#2723); enabling AI after a successful Gemini test has also been reported (#2732).
  • Custom Styles: one enhancement request says the new feature cannot modify templated areas such as the header, described as a regression for users who relied on the previous Custom CSS (#3137).
  • Auth and account: at least one open report describes login and forgot-password failures on the hosted service (#3164).

None of this means the project is broken for everyone. It does mean an operator should reproduce the specific workflows they care about before trusting a deployment, and should plan to keep up with a fast release cadence.

Questions to answer before production

  1. Who will run upgrades? A release every few weeks means upgrades are a recurring task, not a one-time event.
  2. How will you verify rendering after each upgrade? PDF layout has changed across v5 releases, and confirmed bugs remain open.
  3. Do you need AI features, and can you control provider keys, base URLs, and network egress? The AI layer is optional but has the most open configuration issues.
  4. What is your data restore plan? PostgreSQL backups and file-storage redundancy should be tested, not assumed.
  5. Are you comfortable with an open-source project’s priorities? Feature and bug-fix direction is set by maintainers and community triage, not by your business needs.

Verdict

Reactive Resume is a good fit for teams that want a privacy-respecting, customizable resume builder and have the operational capacity to run it. It is actively maintained, MIT-licensed, and the v5.2.7 changes remove server-side styling work while fixing link previews. The conditions attached to that verdict: you must be able to run Docker and PostgreSQL, test PDF exports in your real browsers, verify AI provider configuration before relying on it, and treat upgrades as ongoing maintenance. If you need a no-maintenance resume tool or guaranteed rendering behavior, the hosted service or a commercial alternative is a better fit. As of the 2026-08-21 review, this remains a source and documentation review; nothing here should be read as a tested deployment result.

Sources

If you are deciding whether to run Reactive Resume or already running it and need the upgrade done without downtime, that is the kind of deployment, upgrade, and maintenance work I take on at XP812. That includes moving from earlier v5 releases, removing obsolete PDF environment variables, wiring PostgreSQL backups, testing AI provider connections, and debugging rendering regressions. I can review your current stack, stage and test the upgrade, and leave you with runbooks and monitoring instead of a one-off fix.

Request help