Report Manager servers
Three ways to serve reports. They differ in who designs the reports and in how you integrate them.
All three run the same .rep files, designed with any Report Manager designer.
Start from what you need to do with them — and you can run more than one.
| Server | What it does | Choose it if… |
|---|---|---|
| Web Report Server ( repwebexe) |
Runs a report with its parameters and returns the PDF, over the web. | you already design your reports and only need to run them from your web site or your system. As CGI, as a service with an API, or in Docker. Windows and Linux, more than 20 years in production. |
| Reportman Server | Report store, web designer with an AI copilot, and a public API. | you want your team to design in the browser, with users, groups and permissions, and to run the reports through an API. One Docker container. |
| TCP Report Server | Processes reports for desktop clients over its own TCP protocol. | your clients are desktop applications and you want the server to do the work: multiprocessor, no web in the middle. |
The two web servers, side by side
They are often confused because both are «a report server» and both can run in Docker. The difference is not age: it is whether reports are designed there.
- Web Report Server (
repwebexe) is the veteran: a native binary for Windows and Linux, classically deployed as CGI behind Apache or IIS, now also a service with an API and a published Docker image. It does not design: you upload the.repfiles you designed elsewhere. Details. - Reportman Server is the new one: a container with the engine, the report store and a designer in the browser with an AI copilot, plus its API. It is where reports are born and changed. Details.
You can run both, and many installations will. If you come from
repwebexe, nothing has to change: it keeps serving exactly what it serves today.
Add Reportman Server so your team designs in the browser, and the .rep files that
come out of it are the same ones repwebexe already runs — the TCP server,
the Delphi designer and your own application read them too.
From there you can move your application to the API at your own pace, report by report. There is no switch date and no day on which the old way stops working: a twenty-year-old CGI deployment and a container with the web designer are two doors to the same reports.