Raytha v2.0.0: React admin, PostgreSQL, .NET 10, webhooks

Raytha 2.0.0 is the first release of the 2.0 line. The admin is a new React application, PostgreSQL is the only database, the host runs on .NET 10, and the image is published on Docker Hub as raythahq/raytha:2.0.0.

Released October 2, 2026. This is the largest release since 1.0: nearly every screen in the admin was rebuilt, and the data model was tightened so that the REST API, Liquid templates and the page builder all see the same typed values.

Highlights

A React admin

The admin is now a single-page React application served at /raytha, bundled into the host. It uses the same cookie session as before and talks to /raytha/api/admin and /raytha/api/auth. Old 1.5 admin URLs redirect to the new pages, and sign-in screens are part of the SPA. Error pages, logout, the SAML and JWT sign-in handoffs, theme export and the function test runner remain Razor pages.

PostgreSQL only

One provider, one set of migrations. Raytha now uses PostgreSQL features directly, including jsonb columns and ILIKE search. SQL Server support has been removed; see the breaking changes below for the migration path.

.NET 10

The host targets .NET 10. The VERSION file at the repository root is the product version (2.0.0) and /healthz reports it, so monitoring can tell which build is running.

Outbound webhooks

Subscribe external systems to content events and receive HMAC-signed deliveries. The signature covers the timestamp and the body so a receiver can reject replays. Deliveries are logged and can be retried. See the webhooks guide.

Operations

• An email log that records every message Raytha sends.
• /healthz for liveness and /healthz/ready for PostgreSQL and file storage checks. See health checks.
• Schema export and import, so content types and fields can move between environments.
• Admin impersonation for support, with audit entries.
• Audit log entries are newest first and credentials are redacted from log payloads.

Developer experience

• Raytha Functions are managed in the admin, including public function routes.
• Liquid errors include a line and column, and a web template can be previewed before it is published.
• REST API v1 additions: batch content item create, duplicate theme, background task status, and the remaining theme and content endpoints. API keys have their own admin screen.
• Content list filters are a typed model with bound values. Relationship fields are stored as full Guids and date fields as ISO dates.
• New color and repeater field types, and field-driven widget templates for the page builder.

Security and sign-in

• Magic-link sign-in uses a one-time code instead of a link.
• Manage System Settings and Manage Administrators are full trust: either one grants every system permission.
• Manage Media is its own permission.
• The session cookie is SameSite=Lax in every environment, and proxy trust is explicit through TRUSTED_PROXIES.
• Media URLs are stored relative to the site, and emailed links use the Website URL from organization settings.

Breaking changes

Back up the database before upgrading. The v2_0_0 migration rewrites data, not only the schema. Rolling the migration back does not undo those rewrites, and 1.5 cannot read the converted dates. To go back to 1.5, restore the backup.

Apply the migration by starting with APPLY_PENDING_MIGRATIONS=true, or by running db/Postgres/v1_5_0_to_v2_0_0.sql yourself and leaving that flag false. Both end on the same schema.

• SQL Server is gone. There is no upgrade path from SQL Server. Move the data to PostgreSQL on 1.5.0 first, then upgrade.
• Date fields become ISO dates. 1.x stored them as m/d/yyyy or in the server's culture. Each date field's day/month order is inferred from its own values and rewritten as YYYY-MM-DD, or YYYY-MM-DDTHH:MM:SS when they carried a time, across published content, drafts, revisions and trash. Ambiguous or unrecognizable values are left unchanged and reported as a NOTICE (visible in psql). The README has a query for leftovers.
• Media links in content become root-relative. Absolute URLs to media items in this database lose the scheme and host in content, drafts, revisions, trash and site pages. Links to other sites, and all templates, are left alone.
• Magic-link sign-in uses a one-time code. The magic-link email template and the "magic link sent" page are replaced if they do not already use the code; the previous content is kept as a revision. Links emailed before the upgrade stop working.
• Manage Media is a separate permission. Roles that could reach media before are granted it, so existing admins keep access.
• Built-in widget templates gain field definitions for the 2.0 page builder. Templates that already have fields are not touched.
• Emailed links and API media URLs come from the Website URL in organization settings, not from the request host. A stale Website URL breaks images; set it before upgrading.
• The session cookie is SameSite=Lax in every environment.
• Proxy trust is configured with TRUSTED_PROXIES. Unset means any peer is trusted. If clients can reach Raytha without going through your proxy, set none or list the proxies.

The full upgrade notes are in the README under "Upgrading from 1.5.0" and in our upgrading guide.

Upgrade

The image is on Docker Hub. It listens on port 8080 and does not start the admin dev server.

docker pull raythahq/raytha:2.0.0

Point it at a PostgreSQL database with ConnectionStrings__DefaultConnection, set APPLY_PENDING_MIGRATIONS=true for the first start, and confirm /healthz reports 2.0.0. The Docker guide has a complete compose file.

New to Raytha? The fastest way to run it is the Railway template, which provisions PostgreSQL and the app together. See the quickstart.

Release v2.0.0 on GitHub