Frontforge Report Server 0.9.0

The first public release: a preview of the free Community edition. Frontforge Report Server is a report server you run yourself. You design reports in the browser, and your applications render them as PDF, Word, Excel or HTML from their own data. 1.0.0 follows once people outside Frontforge have run it for a while.

Added

• The designer. A report designer in the browser. Pages show exactly as they will print, because the designer runs the same engine as the server. Drag in text, tables, images, charts and barcodes, then bind them to data with {{ }} fields and formulas. The Inspector edits any element, and the Style panel edits fonts, colours, margins and padding. Tables can insert and remove rows and columns, and merge and split cells. Several elements can be edited at once, and the format painter copies a style from one to another. There are rulers, guides, align and distribute tools, context menus, a command palette and a keyboard shortcut sheet. Every change can be undone. Drafts save as you work, and publishing keeps a history you can roll back.
• RFML, the report language. Every report is an RFML document: JSON, or a markup form for people who prefer to write it by hand. It covers page templates (first, left, right and last pages, backgrounds and a stamp layer), repeating regions, groups, crosstabs, charts, components, sub-reports, footnotes, multi-column flow, parameters and tests. Reports can be translated, and dates and numbers follow the reader's locale. Developers can lock a report's brand colours and fonts while business users edit the rest, text in a form field can shrink to fit it, a group's last rows can be kept with its total, and margins written as start and end mirror in right-to-left reports. The language is specified in docs/spec/rfml.md, version 0.2. The rfml command line validates, formats, converts and renders documents.
• Outputs. PDF, tagged PDF for accessibility (PDF/UA-1), archival PDF (PDF/A-2a, 2b and 3b), HTML as fixed pages or as a flowing page, Word (DOCX) and Excel (XLSX). Fonts are embedded, and a set of open fonts is bundled. SVG images are cleaned of scripts and outside references before they reach any output.
• The viewer. Readers open a report in the browser, at /view/. There they expand and collapse groups, sort, filter, follow drill-through links, change parameters and download the report. Report links, in exported documents and between reports, open a report with its parameters for a signed-in reader, and expire.
• Data. A report renders from data the caller sends, from its sample data, or from a data source: SQL (PostgreSQL, MySQL, SQL Server and SQLite) or HTTP. An administrator sets up the connections, and their secrets stay on the server.
• Libraries. Share components, themes, page templates, images and fonts between reports. A report imports a library by a version range, and publishing pins the release it used, so a new library release changes nothing until a report takes it up. The Libraries page edits and releases libraries, shows which reports use each one, and updates them in bulk. Fonts can be imported from Google Fonts and other sources.
• The API. Render a published report with POST /v1/render, or many at once as a batch job (/v1/jobs). Jobs survive a restart, retry what may pass later, and accept an Idempotency-Key. When a job finishes, a signed webhook can tell your application. Applications sign in with API keys, which expire, can be revoked and can be rotated with an overlap. Every route is described in api/openapi.yaml, and every route has a rate limit.
• MCP agents. AI agents connect over the Model Context Protocol (POST /mcp, or reportd mcp for clients that speak stdio). They read the language reference, edit drafts, preview with sample data, and run a report's tests. An agent acts for a user, with no more access than that user has, and an administrator can require approval before an agent's work is published.
• People and permissions. Users with passwords, two-step sign-in (authenticator apps, passkeys and recovery codes), and sign-in sessions you can see and end. Seven built-in roles and your own, scoped per environment. Templates move between environments (such as dev, test and prod) through git, with promotion and rollback.
• The admin site. At /admin, administrators manage users, roles, API keys and sessions, read the audit log and the usage figures, change settings, install a licence and empty the trash. Deleted templates, folders and libraries go to the trash for 30 days first. The Settings page says what each setting does, finds one by its name, description or value, and changes all but those reportd reads at start. Changes wait until you apply them; reportd then restarts once, in a few seconds. People in the studio and the viewer are told, keep working and lose nothing. A change reportd can't start on is put back, and the page says why.
• Setup and operations. A new install starts in setup mode. The setup wizard, opened with a one-time code from the log, creates the administrator and writes the first settings. Every setting can come from an environment variable. reportd backs up its data, and upgrades it in place after a backup of its own when a new version needs a new format. /livez and /readyz are there for health checks, and logs can be JSON.
• The Community edition. Free, with a Community licence that never expires: get one at https://myaccount.frontforge.com/community with your email address, and give it to the setup wizard. Every install needs a licence, Community included; reportd checks it offline and never calls Frontforge to do so. Community allows 5 templates, 1 sub-report per template and 3 designer seats. It has every output format and PDF standard, the viewer, MCP agents, API keys, batch jobs, libraries, backups and two-step sign-in. It leaves out the assistant, sign-in providers (OIDC and SAML), more than one environment, Postgres state, separate renderd instances, job webhooks and branding. A licence adds them in place, without a reinstall. Community output carries no "Made with Frontforge Report Server" mark. Community is used under the Frontforge Report Server Community Licence: the setup wizard shows it and asks you to accept it, and the release and the image carry it as LICENSE, with the open source components' notices.
• Docker and compose. One container image, for amd64 and arm64, runs reportd with renderd inside it. It is published as ghcr.io/frontforge-corporation/report-server:0.9.0. The compose bundle, report-server-compose-0.9.0.zip, starts it with one command and keeps everything in one volume. Its README says how to read the setup code from the log, back up and upgrade.
• The version, where you can see it. reportd --version and renderd --version print it. GET /v1/info gives reportd's version and its engine's, and the studio shows it in the Account and Licence dialogs.
• A daily version check. Once a day reportd asks GitHub for the latest release, and the studio tells administrators when a newer one is out, with a link to its release notes. The request carries no version, install ID or usage, and there is no other telemetry. Without internet access it fails quietly. Turn it off in the setup wizard, in Admin → Settings (updates.check), or with REPORTD_UPDATES_CHECK=false.

Not in this release

• Installers for Windows and Linux without Docker, and a Docker Hub image. They come later.
• Code signing. The release has checksums and an SBOM instead.
• Email, and with it password reset by email.
• Paid editions. A licence can be installed, but none are sold yet.

The image

docker pull ghcr.io/frontforge-corporation/report-server:0.9.0

For amd64 and arm64. Its digest is sha256:5ab83334ab45845ebe4aa0f6c120f0ce33e28b2916cd9e2a29592c5ef904847e; the compose bundle pins it by version.