> ## Documentation Index
> Fetch the complete documentation index at: https://docs.forge.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Quickstart

> Protect and test one private Resource through a customer-deployed gateway.

This quickstart deploys one Resource gateway, protects a PostgreSQL database,
and verifies an allowed and blocked command. Use a non-production database that
you can reach from a Linux Docker host.

## Before you begin

You need:

* organization administrator access to Forge;
* a Linux host with Docker Compose and outbound HTTPS access to Forge;
* internal DNS for the gateway hostname;
* network access from the gateway host to PostgreSQL; and
* a PostgreSQL account suitable for the test.

## 1. Deploy a Resource gateway

1. Open **Policies → Resources** and choose **New → Resource gateway**.
2. Enter a name and the internal hostname clients will use.
3. Select **Create deployment command** and copy the generated command.
4. Run it on the Docker host. The command creates a version-pinned Compose
   deployment and stores its one-time enrollment value locally.
5. Wait for the gateway to show **Online**.

The host needs inbound TCP `5432` from test clients and outbound access to the
database. See [Deploy a Resource gateway](/resources/deploy-resource-gateway)
for the complete network and secret-handling requirements.

## 2. Create the Resource

1. Choose **New → Resource** and select **PostgreSQL**.
2. Enter its name, destination hostname, port, and database.
3. Assign the Resource gateway you just deployed.
4. If the database uses a private certificate authority, add only its public CA
   certificate under **Private authority**.
5. Save the Resource.

PostgreSQL destination encryption and hostname verification are always on.

## 3. Assign a destination credential

On the Resource page, add a credential for your PostgreSQL test account. Assign
it to yourself or make it the default for this isolated test Resource, then run
**Test connection**.

The test runs from the gateway and verifies DNS, network reachability, TLS, and
destination authentication. The secret is not returned to the client.

## 4. Add a narrow policy

Create a Resource Policy with:

* **Resource:** the PostgreSQL Resource;
* **Condition:** PostgreSQL command equals `DELETE`;
* **Action:** Block;
* **Mode:** Enforce; and
* **Message:** `DELETE requires the approved maintenance workflow.`

Save and enable the policy. Resource Policies use the same conditions,
exceptions, revisions, ownership, and backtests as other Forge policies.

## 5. Connect and verify

Open **Connect directly** on the Resource page. Download the displayed trust
certificate, create a short-lived access credential, and copy the generated
`psql` command. Run one harmless read:

```sql theme={"system"}
SELECT 1;
```

Then run the policy test inside a transaction so no data can change if the rule
is misconfigured:

```sql theme={"system"}
BEGIN;
DELETE FROM forge_resource_test WHERE id = -1;
ROLLBACK;
```

The read should succeed. The `DELETE` should fail before reaching PostgreSQL
and name the responsible policy with your message.

## 6. Review evidence

Open **Live → Resources** and filter by the Resource. Confirm the caller,
protocol, `SELECT` and `DELETE` operations, outcomes, and responsible policy.
Expand the blocked row to review the literal-free query pattern. Forge does not
retain query literals or result values.

To test automatic routing too, enable it on the Resource from a managed device
and repeat the same commands against the database's original hostname. The
policy and activity behavior should be identical.

Continue with [Credentials and identity](/resources/credentials-and-identity),
[Resource Policies](/secure/resource-policies), and
[Activity and approvals](/resources/activity-and-approvals).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.