> For the complete documentation index, see [llms.txt](https://documentation.grax.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.grax.com/technology/requirements/technical-requirements.md).

# Technical Requirements

You bring one compute instance, a PostgreSQL database, a storage bucket, and a URL that Salesforce and your users can reach.

## At a Glance

| Component  | Minimum                                                                              |
| ---------- | ------------------------------------------------------------------------------------ |
| Compute    | x86\_64 (AMD64) or ARM64 Linux, 4 vCPU, 16 GB RAM, 500 GB SSD cache, 5+ Gbps network |
| PostgreSQL | 15+, 2 vCPU, 4 GB RAM, 75 GB disk, `pg_stat_statements`                              |
| Storage    | One S3, Azure Blob, or GCP Cloud Storage bucket; plan for 5 TB to start              |
| Network    | Public domain with a valid certificate, or a Salesforce-configured VPN               |

## Compute

Run one GRAX Application instance on a major cloud provider such as AWS or Azure. The instance can be ephemeral and containerized, since it holds no meaningful state. For high availability, use multi-Availability-Zone (or non-AWS equivalent) deployments with auto-replacement policies.

{% hint style="warning" %}
Only one GRAX Application may run at a time per license; a second instance can cause data and service failures. Avoid "bursting" instances such as AWS `t3` or Azure `B` series: GRAX uses resources continuously, and automatic hibernation under high CPU usage stops backups when your org needs them most.
{% endhint %}

|                  | AWS                                               | Azure                                    | GCP                 |
| ---------------- | ------------------------------------------------- | ---------------------------------------- | ------------------- |
| Instance         | Latest-generation Graviton, `m8g.xlarge` or newer | Standard D4s v3 (4 vCPUs, 16 GiB)        | `n2-standard-4`     |
| Operating system | Amazon Linux 2023                                 | RedHat 8                                 | RedHat 8            |
| Cache disk       | `gp3` EBS volume                                  | Premium SSD with Read/Write host caching | SSD Persistent Disk |

### Cache Disk

GRAX caches data on disk to limit network traffic and improve performance. The cache lives under `/tmp` by default on Linux and must be backed by persistent storage; memory filesystems such as `tmpfs` aren't supported. Mounting a separate disk at `/tmp` isolates the cache and simplifies persistence, replacement, and maintenance.

* If your disk layout requires another path, set the `TMPDIR` environment variable to the new path (for example in the GRAX `.env` file).
* The disk must be an SSD (no HDDs) and meet or exceed the baseline performance of AWS `gp3` EBS volumes.
* Persisting the cache between instance replacements isn't recommended.

## PostgreSQL

GRAX uses PostgreSQL for long-term application metadata storage. The database isn't ephemeral: data loss or availability issues halt the GRAX Application. Only the GRAX instance needs access to it, so don't make it publicly accessible, and authenticate with the username and password in the connection string. For high availability, use multi-Availability-Zone (or non-AWS equivalent) deployments. Use the standard PostgreSQL port, 5432.

{% hint style="warning" %}
GRAX owns the database schema end to end and changes it as needed during normal operation, not only during version upgrades. Tables, indexes, and other objects are created, altered, and dropped at any time while the app runs.

* Don't manage the schema externally, apply manual tuning, or hand-edit rows.
* Don't install DDL triggers, event triggers, or audit rules that block, revert, or alert on schema changes, since they fire during routine GRAX activity.
* Don't restrict the application role to a fixed set of objects.
  {% endhint %}

|            | AWS                                                       | Azure                                                                                                                    | GCP                          |
| ---------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ---------------------------- |
| Service    | Amazon Aurora PostgreSQL or Amazon RDS for PostgreSQL 15+ | Azure Database for PostgreSQL [Flexible Server](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/) 15+ | Cloud SQL for PostgreSQL 15+ |
| Instance   | Latest-generation Graviton, `db.r8g.xlarge` or newer      | Compute Gen 5, 4 vCPUs, 20 GiB                                                                                           | `db-n1-highmem-4`            |
| Storage    | 75 GB to start                                            | 75 GB to start                                                                                                           | 75 GB to start               |
| Extensions | `pg_stat_statements`                                      | `pg_stat_statements`                                                                                                     | `pg_stat_statements`         |

Elsewhere, the minimum is PostgreSQL 15+ with 2 vCPUs, 4 GB RAM, 75 GB of persistent disk, and the `pg_stat_statements` extension.

The credentials used in the final setup of your GRAX Application must have complete permissions on the database and all data within it. GRAX uses many database primitives to optimize performance, so access is broader than a traditional app needs. Burstable instance types are also unsupported for the database (see the Compute warning above). GRAX doesn't use SSL with certificate verification on PostgreSQL, so no action is needed for root certificates or certificate authorities.

{% hint style="info" %}
Your Salesforce record data, metadata, and file binaries aren't stored in PostgreSQL. They're written to your storage bucket, and this database holds application metadata. See [Blob Storage](/technology/overview/blob-storage.md) for how the dataset is stored.
{% endhint %}

### Backup and Recovery

In a self-managed deployment, the database runs in your own environment, so backing it up and restoring it are your responsibility. GRAX has no access to it and can't snapshot, restore, or recover it on your behalf. Plan for recovery before you need it:

* Take daily snapshots with a retention of more than a month, using your cloud provider's managed backup features where available.
* Enable point-in-time recovery if your platform supports it.
* Document the restore procedure and test it periodically rather than assuming the snapshots are usable.
* Keep the same expectations for any database maintenance you perform, such as version upgrades and instance resizing.

For GRAX Cloud and GRAX-managed deployments, see [Shared Responsibility](/technology/security/security.md#shared-responsibility). For what falls inside and outside GRAX support obligations, see the [support documentation](https://documentation.grax.com/support).

## Storage Bucket

GRAX stores your Salesforce data long term in an AWS S3, Azure Blob Storage, or GCP Cloud Storage bucket. These features and tiers aren't supported:

| Provider                      | Not supported                                                                   |
| ----------------------------- | ------------------------------------------------------------------------------- |
| AWS S3                        | Versioning, Object Lock, Glacier, Intelligent-Tiering, Outposts, S3 Replication |
| Azure Blob / Data Lake (gen2) | Premium accounts, Data Lake gen1, any tier other than Hot                       |
| GCP Cloud Storage             | Nearline, Coldline, Archive                                                     |

* **Access:** only the GRAX instance needs access; don't make the bucket publicly accessible.
* **Permissions:** the credentials used in the final setup must be able to delete, get, update, and create all contents of the bucket. If you use encryption at rest (AWS KMS), also grant permission to use the keys and perform encryption operations on all objects in the bucket.
* **Object lifecycle:** GRAX creates and deletes objects over the lifetime of the app to maintain its proprietary data format. It never updates data-containing objects in place.
* **Sizing:** bucket size depends on many factors and is hard to predict. Plan for 5 TB to start for the average customer; usage grows over time.

## Network Accessibility

Your GRAX service must be reachable publicly through a registered domain name with a valid certificate, or through a Salesforce-configured VPN connection to your private network. Salesforce and your end users both reach GRAX at this address. See [Network Requirements](/technology/requirements/network-requirements.md) for the traffic rules and for choosing a URL and certificate.

## Recommended Additions

* An ALB in front of the instance for ingress traffic, for high availability and quality of service (see [TLS/SSL Certificates](/technology/requirements/network-requirements.md#tls-ssl-certificates) for handling certificates on custom domains).
* An autoscaling group with a size of `1` for auto-replacement and recovery.
* Ingress and egress filtering (for example a GRAX Application firewall and/or VPC gateway), as most enterprise cloud teams use for all resources.

Infrastructure outside the minimums on this page can't be guaranteed to perform as expected, and may cause unpredictable behavior, degraded performance, and support challenges.