# Setting Up a New ORDS DB Pool for the API Gateway

Adding a new REST-enabled database pool to Oracle REST Data Services (ORDS) is one of those tasks that's simple once you've done it — but easy to get wrong the first time if you're piecing it together from scattered docs. Here's a clean walkthrough of standing up a dedicated `api` pool and routing traffic to it through Apache.

## 1\. Create the API DB Pool

From the ORDS `bin` directory, run the install command in config-only mode, targeting your existing ORDS config folder:

```bash
cd /opt/ords/24.1/bin
./ords --config /etc/ords/myapp-prod/ install --config-only --db-pool api --admin-user SYS \
  --db-hostname db-host.example.com --db-port 1521 --db-servicename myapp.example.com \
  --feature-sdw true --feature-rest-enabled-sql true --gateway-mode proxied --gateway-user APP_SELFSERVICE \
  --proxy-user --password-stdin << 'EOF'
your_ords_public_user_password
your_proxy_user_password
EOF
```

A few things worth calling out about this command:

*   `--config-only` means ORDS just writes the pool configuration — it doesn't touch the schema or attempt a full install, which is what you want when you're adding a pool to an already-running instance.
    
*   `--gateway-mode proxied` combined with `--gateway-user APP_SELFSERVICE` and `--proxy-user` sets this pool up to connect through a proxy user rather than authenticating directly as the schema owner.
    
*   `--feature-sdw true` and `--feature-rest-enabled-sql true` turn on Schema Design Workshop and REST-enabled SQL for this pool.
    
*   You'll be prompted for the `ORDS_PUBLIC_USER` password, or you can pipe it in via `--password-stdin` as shown above.
    

### Verify the pool

Once it's created, confirm the configuration landed the way you expect:

```bash
./ords --config /etc/ords/myapp-prod/ config list --db-pool api
```

### Restart and tail the logs

```bash
systemctl restart ords-myapp-app.service
journalctl -f -n 500 -u ords-myapp-app.service
```

Keep the `journalctl` tail open while the service comes back up — this is the fastest way to catch a bad hostname, port, or credential before it turns into a support ticket.

## 2\. Modify httpd.conf

With the pool live on the ORDS side, the last step is telling Apache how to route requests to it.

Open `httpd.conf` and find the existing block that proxies your back-office pool — look for the `ProxyPass` lines pointing at your ORDS backend port (commonly `8080`). Duplicate that block and change only the path prefix so it points at the new `api` pool:

```apache
ProxyPass        /myapp/apps/api  http://<ords-backend-host>:8080/api/
ProxyPassReverse /myapp/apps/api  http://<ords-backend-host>:8080/api/
```

A couple of guardrails here:

*   `<ords-backend-host>` and the port **must match** whatever your existing back-office `ProxyPass` block already uses — don't guess a new host or port, mirror what's already working.
    
*   This new block needs to live inside the **same** `<VirtualHost>` **section** as your existing ORDS proxy rules, not a separate one.
    

### Test and reload

Always validate the config before reloading a production Apache instance:

```bash
httpd -t
systemctl reload httpd
```

`httpd -t` will catch syntax errors before they take the whole vhost down — never skip straight to `reload`.

## A note on the httpd.conf block

Since every environment's `httpd.conf` differs, the exact host, port, and surrounding directives in your file may not match the example above one-to-one. If you paste in the current back-office `ProxyPass` / `ProxyPassReverse` lines from your own `httpd.conf`, it's straightforward to mirror them exactly for the new `api` path rather than guessing at the values.

* * *

That's the full loop: provision the pool in ORDS, verify it, restart the service, and then extend the Apache proxy config so external requests actually reach it. Small task, but one where following the existing patterns in your config — rather than improvising new ones — is what keeps it boring (in the good way).