How to Resolve the Unstyled Page Error in Oracle APEX on Autonomous Database

Is your Oracle APEX application loading without CSS or styles? Learn how to quickly fix the 'Oracle APEX files have not been loaded' error on Oracle Autonomous Database (ADB).

☁️ Pre-Flight Checklist

Before we taxi down the runway, here’s your flight plan. Keep this handy to navigate your flight path. Welcome aboard the cloud!

🌥️ Takeoff

• The One-line Summary
• What The Error Actually Means
• Why It Happens (especially "for the first time")

⛅️ Cruising Altitude

• Where To Run The Fix (You Don't Need a Working APEX UI)
• First Attempt: Reset To /i/ (May Or May Not Be Enough)
• Root Cause: ORDS Version Mismatch
• Is This Safe & Is It Reversible?
• A Note On Custom Domains / Reverse Proxies

🌤️ Landing & Taxi

• The Most Important Takeaway: Make It Self-Correcting
• When to Involve Oracle Support
• TL;DR Checklist

Enjoy your flight! ☁️

---

In the event that you open your APEX app or even APEX's own builder login and instead of the usual polished UI you get a wall of plain serif text, blue underlined links, and a popup that says the following:

There is a problem with your environment because the Oracle APEX files have not been loaded. Please verify that you have copied the images directory to your application server... Your current path is /i/24.2.17/ ... Use the SQL script reset_image_prefix.sql if you need to change it.

If you're on Oracle Autonomous Database (your URL looks like something.adb.<region>.oraclecloudapps.com), most of that error message is misleading for your situation, and chasing it literally will waste your time. This article walks through what's actually happening, how to fix it fast, and, importantly, how it can come back and how to make the fix self-correcting.

I went through this on a live instance where users were locked out, so the steps below are the path that actually worked, including the dead ends, so you can skip them.

The One-line Summary

On a managed autonomous database you can't "copy the images directory", and you can't run reset_image_prefix.sql because you have no file system access. The fix is to set the APEX IMAGE_PREFIX parameter, and if your local ORDS has a version mismatch, the most reliable target is Oracle's CDN for your exact APEX version.

If you just want the fix, jump to "The fix that works". If you want to understand it, keep reading.

What The Error Actually Means

Every page APEX renders pulls its styling and icons (CSS, JavaScript and fonts) from a base path called the image prefix. The default is /i/. When APEX asks for those files at the configured prefix and gets nothing back, it shows the bare HTML page and that popup. The giveaway is that everything APEX serves loses its styling, including the internal admin and builder pages, not just one app you built. That tells you it's an instance-level problem, not an app-level one.

So the real question is never "Did I copy the images directory?" (On Autonomous Database, Oracle handles that). The real question is: what is the image prefix set to, and is anything serving files there?

Why It Happens (especially "for the first time")

This tends to surface around a discrete event rather than during normal use, which is why it can feel like it came out of nowhere after months of everything working:

• An APEX patch or upgrade. Oracle patches APEX on Autonomous Database periodically. Around a patch cycle, the image prefix can end up pointing at a version-specific path (like /i/24.2.17/) instead of the plain /i/ that the managed ORDS actually serves. Versioned local paths only work with the CDN or a customer-managed ORDS not the default managed setup, so they silently break.

• A manual or imported config change. Lots of tutorials show setting IMAGE_PREFIX to a versioned path for CDN use. If that value was copy-pasted in (or carried over by a migration) without the full CDN host, you get a path nothing serves.

In my case the prefix was /i/24.2.17/, a malformed half-CDN reference: it had the version but not the https://static.oracle.com/cdn/apex/ host in front of it, so it resolved to a local path ORDS wasn't serving.

Where To Run The Fix (You Don't Need a Working APEX UI)

Since the APEX UI itself is broken, fix this from Database Actions, which is separate from APEX:

1. Go to the OCI Console (cloud.oracle.com) and sign in.
2. Hamburger menu → Oracle Database → Autonomous Database.
3. Pick the right region/compartment, click your database.
4. Click the Database actions dropdown → SQL.
5. It opens the SQL Worksheet, already authenticated as the ADMIN database user. A few gotchas I hit here:

• /ords/admin/ gives a 404. That's not a real page; don't navigate to it directly. Launch Database Actions from the OCI Console instead. (If you do need the direct sign-in page, it's /ords/sql-developer.)

• The sign-in wants a database user, not your APEX workspace admin. I tried my APEX workspace admin and got "Invalid credentials". The login here needs the database master user, ADMIN, with the master password you set at database creation (resettable in the OCI Console). ADMIN ≠ your APEX workspace admin. They're separate accounts.

First Attempt: Reset to /i/ (May or May Not Be Enough)

The textbook fix is to set the prefix back to the default /i/:

BEGIN
    APEX_INSTANCE_ADMIN.SET_PARAMETER('IMAGE_PREFIX', '/i/');
    COMMIT;
END;
/

Run it with Run Script (F5) — it's a PL/SQL block, not a single statement. Verify:

SELECT APEX_INSTANCE_ADMIN.GET_PARAMETER('IMAGE_PREFIX') FROM dual;

Then hard-refresh APEX (Cmd/Ctrl+Shift+R, or use an incognito window to be sure caching isn't lying to you).

If your styling comes back, you're done. For many people this is the whole fix.

In my case it wasn't — the error came back, but now it said "Your current path is /i/". So the prefix was correct, yet the files still weren't loading. That moves the diagnosis somewhere more interesting.

Root Cause: ORDS Version Mismatch

In Database Actions I had a persistent warning:

Version Mismatch — The ORDS running version and the ORDS versions installed in the database are not the same. Some functionality may be disabled.

That's the root cause. When ORDS's running version doesn't match the APEX version in the database, ORDS may serve a different version's static files (or none) at /i/, and APEX's "are my files loaded?" check fails even though the prefix is correct.

You can confirm it directly. Open in a browser (swap in your hostname):

https://<your-host>.oraclecloudapps.com/i/apex_version.txt

A 404, or a version number that doesn't match your database's APEX version, confirms the local /i/ route can't be trusted.

The Fix That Works

Sidestep the local ORDS entirely by pointing the image prefix at Oracle's CDN for your exact APEX version. The CDN serves the static files directly, so it doesn't matter what local ORDS is doing.

First, find your exact APEX version (note the column is version_no, not version):

SELECT version_no FROM apex_release;

Mine returned 24.2.17. Then set the prefix to the CDN. Use Oracle's documented loop form rather than hardcoding the version — it reads version_no straight from the database and builds the path itself, so there's no typo risk:

BEGIN
    FOR c1 IN (SELECT version_no FROM apex_release) LOOP
        APEX_INSTANCE_ADMIN.SET_PARAMETER(
            p_parameter => 'IMAGE_PREFIX',
            p_value     => 'https://static.oracle.com/cdn/apex/' || c1.version_no || '/'
        );
    END LOOP;
    COMMIT;
END;
/

Verify:

SELECT APEX_INSTANCE_ADMIN.GET_PARAMETER('IMAGE_PREFIX') FROM dual;
-- expect: https://static.oracle.com/cdn/apex/24.2.17/

Sanity-check that the CDN actually has your version by opening this in a browser:

https://static.oracle.com/cdn/apex/24.2.17/apex_version.txt

If you get back something like Oracle APEX Version: 24.2, the CDN is serving it. Now open your app in a fresh incognito window and it should render fully styled, login and all.

If the page is still unstyled, the CDN doesn't carry your exact patch level (only the base release and certain bundles are guaranteed). At that point the styling can only come from a healthy local ORDS, and the version mismatch is the thing to fix.

Is This Safe & Is It Reversible?

Yes to both, and it's worth being precise about why:

• IMAGE_PREFIX is a single string parameter. Changing it does not touch app definitions, pages, users, authentication, data, or uploaded files. It's a pointer.

• It's fully reversible, just set the string back to a previous value any time. (Reverting to the original broken value isn't useful, since that reproduces the problem, but it's possible.)

• Setting the prefix triggers APEX to recompile some objects in its own schema. This is routine and automatic, happens the same way regardless of the value, and isn't a one-way door.

• The worst realistic outcome from the CDN change is "no visible improvement", not data loss or a broken app. If your app is already down, there's no working state to protect, so running it is the right call.

A Note On Custom Domains / Reverse Proxies

If you front APEX with a custom domain (I use Caddy reverse-proxying to the ORDS endpoint), the CDN fix is actually better for you, not riskier. The IMAGE_PREFIX change is made inside the database and applies no matter which hostname users arrive through. And because the CDN value is a full https://static.oracle.com/... URL, the browser fetches those static files directly from Oracle's CDN and they never pass through your proxy at all. Your proxy is left handling only the dynamic traffic (page HTML, form posts, and session cookies), which is what its header rewrites are there for. Both your domain and the CDN are HTTPS, and the CDN is built to be loaded cross-origin, so there's no mixed-content or CORS issue.

One distinction that tripped me up and is worth getting right:

• Instance-level IMAGE_PREFIX (what we set) controls only APEX's own engine files (the #IMAGE_PREFIX# assets). Your uploaded Static Application Files (#APP_FILES#) keep being served normally by ORDS from the database. Nothing about your custom files breaks.

• It's the separate application-level "Static File Prefix" (Shared Components → User Interface Attributes) that, if pointed at the CDN, would also redirect #APP_FILES# and force you to host custom files elsewhere. We did not touch that, so it's a non-issue here.

The Most Important Takeaway: Make It Self-Correcting

Here's the part to remember, because this can come back:

Because the CDN path is pinned to a specific version (24.2.17), a future APEX patch will leave the prefix pointing at the old version's files, and the page can break again. The fix at that point is the same one-liner you just ran. The loop reads the current version_no automatically, so it self-corrects each time you run it. Bookmark that command.

So keep this handy and re-run it after any APEX patch:

BEGIN
    FOR c1 IN (SELECT version_no FROM apex_release) LOOP
        APEX_INSTANCE_ADMIN.SET_PARAMETER(
            p_parameter => 'IMAGE_PREFIX',
            p_value     => 'https://static.oracle.com/cdn/apex/' || c1.version_no || '/'
        );
    END LOOP;
    COMMIT;
END;
/

When to Involve Oracle Support

The CDN approach routes around the ORDS version mismatch, it doesn't resolve it. On a managed Autonomous Database you can't re-sync ORDS yourself. If you want the underlying mismatch properly cleaned up (or if the CDN doesn't carry your exact patch level), open an OCI service request: from the database's detail page, check lifecycle state and any pending Maintenance first, then file the SR from Help → Create support request, citing the ORDS/APEX version mismatch and asking them to re-sync ORDS.

---

TL;DR Checklist

1. Don't take the error literally — on Autonomous Database you can't copy files or run reset_image_prefix.sql.
2. Open Database Actions → SQL from the OCI Console, signed in as ADMIN (not your APEX workspace admin).
3. Try IMAGE_PREFIX = '/i/' first. If styling returns, done.
4. If not, check for a Version Mismatch warning and test /i/apex_version.txt.
5. Point IMAGE_PREFIX at the CDN using the version_no loop. Verify and test in incognito.
6. Re-run that loop after any future APEX patch. Bookmark it.
7. File an OCI service request if you want the ORDS mismatch itself resolved.

Hope this saves someone the detour. It's a config pointer, not a catastrophe. Your apps and data are never at risk.

---

Cover Photo by BoliviaInteligente on Unsplash