It's 11:47 PM. You just spent three hours perfecting a Dynamic Action on Page 14. The validation logic is chef's kiss. The CSS is pixel-perfect. You test it one last time, and it works.

You go to bed happy.

The next morning, your colleague messages you: "Hey, I made some changes to Page 14. Hope that's okay."

It is not okay.

Your Dynamic Action is gone. Your CSS is overwritten. Three hours of work - vanished into the database like it never existed.

If this has ever happened to you (or if you just felt a chill reading it), this post is for you.

I'm going to show you the simplest possible way to add version control to your Oracle APEX projects. No complex CI/CD pipelines. No terminal commands. No DevOps certification required.

Just PL/SQL, GitHub, and about 15 minutes of your time.

The APEX Developer's DevOps Problem

Let's be honest. Most APEX developers hear "DevOps" and immediately think:

"That's for React developers and Kubernetes people. I build apps in a browser. My code lives in the database. Git doesn't apply to me."

And honestly? I get it.

Traditional version control assumes you're working with files on disk. But APEX stores everything - pages, regions, processes, Dynamic Actions, templates - inside Oracle Database tables. There are no .js files to commit. No project folder to git init.

Here's what most APEX teams do instead:

• Export the app as a SQL file before making big changes (sometimes)
• Name it f100_backup_oct_final_v2_FINAL.sql (always)
• Store it in a shared drive folder that nobody organizes (inevitably)
• Pray that nothing goes wrong (religiously)

This is not DevOps. This is hope-driven development.

And the real cost isn't just lost code. It's the fear of making changes. When you don't have a safety net, every edit to a production app feels like defusing a bomb.

So what's the fix?

Plot Twist: Your Database Already Has Git Powers

Here's something most APEX developers don't know:

If you're running on Oracle Autonomous Database (even the Always Free tier), you already have a PL/SQL package called DBMS_CLOUD_REPO sitting in your database. Right now. Doing nothing. Waiting for you.

This package lets you:

• Create GitHub repositories from PL/SQL
• Push database objects (tables, packages, views) directly to Git
• Export your entire APEX application to Git - split into individual files per page
• Pull scripts from Git and run them in your database

All from SQL Workshop. No terminal. No command line. No Docker. No YAML files.

Just write PL/SQL. Push to GitHub. Done.

Let me walk you through it.

The Setup (One-Time, ~10 Minutes)

1. Get a GitHub Personal Access Token

Go to GitHub → Settings → Developer settings → Personal access tokens → Tokens (classic) → Generate new token.

Check the repo scope. Copy the token (starts with ghp_). You'll need it once.

2. Store the Credential in Your Database

BEGIN
  DBMS_CLOUD.CREATE_CREDENTIAL(
    credential_name => 'GITHUB_CRED',
    username        => 'your-github-username',
    password        => 'ghp_your_token_here'
  );
END;
/

That's it. Your database now knows how to talk to GitHub.

3. Create a Repository (From PL/SQL!)

DECLARE
  l_repo CLOB;
BEGIN
  l_repo := DBMS_CLOUD_REPO.INIT_GITHUB_REPO(
    credential_name => 'GITHUB_CRED',
    repo_name       => 'my-apex-project',
    owner           => 'your-github-username'
  );

  DBMS_CLOUD_REPO.CREATE_REPOSITORY(
    repo        => l_repo,
    description => 'My APEX App - Version Controlled',
    private     => TRUE
  );
END;
/

Go check GitHub. You now have a private repository. You created it from SQL Workshop. Let that sink in.

Pushing Code to GitHub

Export a Database Object

DECLARE
  l_repo CLOB;
BEGIN
  l_repo := DBMS_CLOUD_REPO.INIT_GITHUB_REPO(
    credential_name => 'GITHUB_CRED',
    repo_name       => 'my-apex-project',
    owner           => 'your-github-username'
  );

  -- Push a table's DDL to Git
  DBMS_CLOUD_REPO.EXPORT_OBJECT(
    repo        => l_repo,
    object_type => 'TABLE',
    object_name => 'EMPLOYEES_T',
    file_path   => 'db/tables/EMPLOYEES_T.sql'
  );

  -- Push a package
  DBMS_CLOUD_REPO.EXPORT_OBJECT(
    repo        => l_repo,
    object_type => 'PACKAGE',
    object_name => 'EMPLOYEES_PKG',
    file_path   => 'db/packages/EMPLOYEES_PKG.sql'
  );
END;
/

Every call creates a commit in your GitHub repo. Real version history. Real diffs.

Export Your Entire Schema

DECLARE
  l_repo CLOB;
BEGIN
  l_repo := DBMS_CLOUD_REPO.INIT_GITHUB_REPO(
    credential_name => 'GITHUB_CRED',
    repo_name       => 'my-apex-project',
    owner           => 'your-github-username'
  );

  DBMS_CLOUD_REPO.EXPORT_SCHEMA(
    repo        => l_repo,
    file_path   => 'db/',
    schema_name => 'YOUR_SCHEMA'
  );
END;
/

All your tables, views, packages, sequences - exported to GitHub in one call.

The Big One: Export Your APEX Application

This is where it gets really good.

DECLARE
  l_repo  CLOB;
  l_files APEX_T_EXPORT_FILES;
BEGIN
  l_repo := DBMS_CLOUD_REPO.INIT_GITHUB_REPO(
    credential_name => 'GITHUB_CRED',
    repo_name       => 'my-apex-project',
    owner           => 'your-github-username'
  );

  -- Split export: one file per page, 
  -- shared component, etc.
  l_files := APEX_EXPORT.GET_APPLICATION(
    p_application_id => 100,
    p_split          => TRUE
  );

  -- Push every file to GitHub
  FOR i IN 1 .. l_files.COUNT LOOP
    DBMS_CLOUD_REPO.PUT_FILE(
      repo      => l_repo,
      file_path => 'apex/' || l_files(i).name,
      contents  => l_files(i).contents
    );
  END LOOP;
END;
/

The p_split => TRUE flag is the secret ingredient. Instead of one massive SQL file, it creates separate files for each page, each shared component, each authorization scheme. Now when you look at the Git diff, you see exactly which page changed and what changed on it.

What You Get

Once you've pushed your first export, open your GitHub repo. You'll see something like this:

my-apex-project/
├── apex/
│   └── f100/
│       ├── install.sql
│       ├── application/
│       ├── pages/
│       │   ├── page_00001.sql
│       │   ├── page_00014.sql   ← your precious Page 14
│       │   └── ...
│       └── shared_components/
├── db/
│   ├── tables/
│   │   └── EMPLOYEES_T.sql
│   └── packages/
│       └── EMPLOYEES_PKG.sql

Now every time you re-export and push:

• GitHub shows you the diff - exactly which lines changed on which page.
• You have commit history - scroll back to any previous version of your app.
• Rollback is one click away - find the last working version, copy the SQL, run it.
• Your colleague's changes are visible - no more mystery overwrites.

That Dynamic Action you lost at 11:47 PM? Never again.

This isn't a full CI/CD pipeline with automated deployments and blue-green strategies. But honestly? For most APEX teams, it doesn't need to be. Having any version history is infinitely better than having none. And this approach gets you there in 15 minutes, using tools you already know.

TL;DR

What's Next? (Part 2 Teaser)

This post covered the "lazy" approach - and for solo developers or small teams, it might be all you ever need.

But what if you want:

• Automated exports on a schedule?
• A CI/CD pipeline that deploys to TEST on every push?
• Pull requests and code reviews for APEX changes?
• OCI DevOps integration with build and deployment pipelines?

That's Part 2 - where we graduate from "lazy" to "serious" DevOps. Coming soon (if this post gets enough love 😄).

If you found this useful, share it with an APEX developer who's still naming their backups _final_v3_REAL.sql. They'll thank you.

Have you tried version-controlling your APEX apps? What approach do you use? Let me know in the comments.