The Complete Oracle APEX 26.1 Server Stack

This is the map for the whole series. Before we touch a single command, it helps to see the shape of what we are building: a complete Oracle APEX 26.1 server, from the database at the bottom to the HTTPS request that reaches a user's browser at the top. The tutorials that follow each build one layer of this stack. This one explains how the layers fit together and why the boundaries between them are drawn where they are.

If you have ever set up a web application behind a reverse proxy, the overall pattern will feel familiar. APEX is unusual in that the "application server" is really the database itself: the application logic lives in the database, and a thin middle tier translates web requests into database calls. Understanding that single idea makes the rest of the build sensible.

Every hostname, IP address, password, and organization name in this series is an illustrative placeholder. You will see example.com, app.example.com, and a private-range address like 192.168.10.20. Substitute your own values throughout. A real public deployment uses a routable public IP and your own domain.

The three-tier architecture

The stack has three tiers stacked on a single server, each with a narrow job. A request travels down through them and the response travels back up.

1. Web tier - Apache httpd 2.4.62. The browser connects over HTTPS to https://example.com or https://app.example.com. Apache terminates SSL on port 443, then acts as a reverse proxy, forwarding the decrypted request inward. This is the only tier the internet talks to directly.
2. Application tier - Apache Tomcat 9.0.117 running ORDS 26.1.0. Oracle REST Data Services (ORDS) is packaged as a WAR file (a Web Application Archive) that runs inside the Tomcat servlet container. ORDS is the bridge: it turns an HTTP request into a PL/SQL call inside the database and turns the result back into an HTTP response. Tomcat listens on port 8080, bound to 127.0.0.1 only.
3. Database tier - Oracle AI Database 26ai. The container database (CDB) is named ORCLCDB, and APEX lives in a dedicated pluggable database (PDB) named APEX_PDB. The APEX engine installs as the schema APEX_260100. The database listener answers on port 1521, again bound to localhost. This is where the application actually runs.

Read top to bottom, the path is: browser over HTTPS -> Apache (SSL termination and reverse proxy, port 443) -> Tomcat running the ORDS WAR (port 8080, localhost only) -> Oracle Database 26ai with APEX installed in APEX_PDB (port 1521). The database does the work; the two tiers above it exist to get a safe, encrypted request to it and a clean response back.

The security posture

The reason for binding Tomcat and the database listener to localhost is the heart of the design. Only port 443 (HTTPS) and port 80 (HTTP redirect) are exposed to the internet. Tomcat's port 8080 and Oracle's port 1521 are reachable only from the server itself.

That means there is exactly one front door. Apache holds the certificate and is the single place where TLS is configured and where you reason about what the outside world can reach. Tomcat never has to defend itself against the open internet, and the database listener is invisible from outside the host. If you have run an application server behind nginx or HAProxy, this is the same instinct: keep the application processes private, and let a hardened proxy own the public edge.

Mail flow at a glance

APEX sends email through the database, not directly to your mail provider. The flow is short:

APEX_MAIL.SEND() -> Postfix on localhost -> provider SMTP relay over TLS on port 587 -> recipient.

APEX hands the message to a local Postfix instance, and Postfix relays it onward to your mail provider over an authenticated TLS connection. Keeping a local relay in the middle means APEX only ever talks to localhost, and all the provider credentials and TLS settings live in one place. Tutorial 06 builds this end to end.

Server specifications

The build assumes a modest single server. These values are the reference point for the whole series; the memory tuning in Tutorial 01, in particular, is derived from the 8 GB of RAM listed here, so note your own figure if it differs.

Everything here - hostnames, the IP, the Oracle paths - is illustrative. The paths matter because later tutorials reference them, so if you change /opt/oracle or the PDB name, change them consistently across every step.

What APEX 26.1 adds at the application tier

Two features are new in this release, and it is worth knowing they exist even though neither changes the server build below.

• APEXlang - a Git-friendly text representation of applications. It makes APEX applications easier to track in version control and review as text.
• Built-in generative AI providers - out-of-the-box support for Anthropic Claude, OpenAI, Gemini, OCI, and more, configurable inside APEX.

Both are application-tier features you enable after the install is finished. They do not affect how you tune the OS, create the PDB, or stand up ORDS and Apache. The server you build in Tutorials 01 through 05 is the same whether or not you ever use them.

The roadmap

Here is what each tutorial in the series builds, in order:

1. Tutorial 01 - Preparing AlmaLinux 9 and Oracle 26ai for APEX. Kernel parameters, user limits, Transparent Huge Pages, and the database memory and redo settings that make the host stable.
2. Tutorial 02 - Creating APEX_PDB and Installing APEX 26.1. A dedicated pluggable database, its four tablespaces, and the APEX engine itself.
3. Tutorial 03 - The Middle Tier: JDK 21, Tomcat, and ORDS. Oracle JDK 21, a locked-down Tomcat, and ORDS 26.1.0 deployed and installed into APEX_PDB.
4. Tutorial 04 - Apache Reverse Proxy and SSL for APEX. The reverse proxy that forwards to Tomcat, and a commercial multi-domain SSL certificate.
5. Tutorial 05 - Landing Pages, Password Expiry, and ORDS Schema Fixes. The operational details that keep a working install from quietly breaking later.
6. Tutorial 06 - Sending Email from APEX with Postfix. The localhost mail relay described above, configured and tested.
7. Tutorial 07 - Creating an APEX Developer Schema (APEX_DEV). A properly privileged workspace schema to build applications in, separate from the APEX engine schema.

What you have now: a mental model of the whole stack - which tier does what, what is exposed and what is not, how mail leaves the box, and what each remaining tutorial adds. Next up is Tutorial 01, where we tune AlmaLinux 9 and Oracle 26ai so the database has a stable foundation to run on.