ApexReporter StudioDeployment footprint
| Component | What it takes |
|---|---|
| Application server | None — a single compiled Node.js process serves both the REST API and the designer UI from one port. |
| Repository database | None to provision — an embedded SQLite-based metadata store ships inside the process itself. |
| Oracle client software | None — connections run in Oracle's thin mode, pure network protocol. |
| Disk footprint | ~1.5 GB for the full runtime, dependencies, metadata storage, and logs. |
| Minimum hardware | 2 cores / 4 GB RAM; 8 GB+ recommended alongside a local Oracle instance. |
| Reverse proxy | Recommended in front (nginx, IIS, or ORDS/HTTP Server) to terminate HTTPS — the app itself speaks plain HTTP. |
Compare that to Oracle Reports Server (a full Oracle Fusion Middleware/WebLogic install) or JasperReports Server (Java + Tomcat + its own repository database) — both are a dedicated middle-tier stack in their own right. This is one process.
Where it sits
Run it on the same host as your APEX/ORDS mid-tier, or on its own machine on the same network — either works, since it talks to Oracle directly over the network and talks to APEX pages over HTTPS, not through any shared application-server session. Multiple APEX applications, even on different Oracle databases, can all call the same ApexReporter Studio instance, each authenticated by its own service-caller API key.
API-first, not UI-first
- Every capability is a documented REST call, not just a button in the designer — a hand-written OpenAPI 3.0 spec is always public to read.
- A small JavaScript client (
ApexReporter.run()/.preview()) is purpose-built for APEX Dynamic Actions — see the installation & integration guide. - Headless/unattended callers — a scheduled job, another backend service — are first-class, not an afterthought; the same trusted service-caller API key that authenticates an APEX Dynamic Action authenticates a server-to-server call.
Self-hosted on your own infrastructure — your data and query results never leave your network. Connection passwords are encrypted at rest; role-based access control and a full audit trail cover the designer/admin side. See the documentation's security section for the full detail.
Stand it up next to your own APEX/ORDS mid-tier
The downloadable trial installs the same way a production instance would.
Installation Guide Download Trial