# Access a database

You can access a database within your project or through local forwarding. Supported addons also offer public access or [VPC access](#expose-a-database-to-the-vpc) on eligible BYOC clusters.

By default, a database will be given an internal address and only be accessible from services and jobs within the same project. You will still be able to access it locally using [port forwarding](https://northflank.com/docs/v1/api/forwarding) through the Northflank CLI.

![The network settings page for an addon in the Northflank application](https://assets.northflank.com/documentation/v1/application/databases-and-persistence/access-a-database/addon-network-page.png)

## Deploy a database with TLS

If you enable TLS, the database uses it for all internal connections.

Some databases, such as MySQL, cannot enable or disable TLS after creation and will use the configuration they were created with.

To enable TLS on a running database that supports changing it:

1. Open Network → Settings in the addon menu.

2. Enable Deploy with TLS.

3. Click Update & restart.

Your deployments may require further configuration to connect to your database if TLS is enabled, the TLS status will be reflected in the connection detail secret `TLS_ENABLED` as a boolean.

## Expose a database publicly

Public exposure requires a supported, running database with TLS and a public ingress load balancer installed and ready on the cluster. An addon can use public or [VPC exposure](#expose-a-database-to-the-vpc), but not both.

Some databases, such as MySQL, cannot enable or disable TLS after creation and will use the configuration they were created with.

To enable public access:

1. Open Network → Settings in the addon menu.

2. If TLS is disabled, enable Deploy with TLS.

3. Select Public under Accessibility.

4. If you also change TLS, click Update & restart. Otherwise, click Update.

The database accepts public connections through a TCP endpoint secured with TLS. The updated connection strings appear under Network → Connection details.

## Expose a database to the VPC

Eligible BYOC clusters can expose supported databases and addons through a private ingress load balancer. Clients need network connectivity to the VPC. See [Public and VPC ingress](https://northflank.com/docs/v1/application/bring-your-own-cloud/configure-your-cluster#public-and-vpc-ingress) for availability and cluster requirements.

For either public or VPC ingress:

> [!note] Requirements
>
> You will need the following to get started:
>
> - An addon type that supports TLS and external access
> - A running addon when changing its network configuration
> - TLS enabled with `tlsEnabled: true`
> - The corresponding public or private ingress load balancer installed and ready on the cluster

Saving the cluster's ingress configuration does not mean that the load balancer is ready. TLS changes after addon creation also depend on addon-type support.

> [!warning] Before changing addon exposure
>
> Plan client access before switching between public and VPC exposure. The change interrupts access through the previous path. Addons cannot use both ingress paths at once.

Addons have three exposure choices:

| Accessibility | `externalAccessEnabled` | `vpcAccessible` | Access |
| --- | --- | --- | --- |
| Private | `false` | `false` | Internal only |
| Public | `true` | `false` | Public ingress |
| VPC | `false` | `true` | Private ingress |

The fields `externalAccessEnabled` and `vpcAccessible` cannot both be `true`. Addons do not support the service-port Public and VPC choice. Internal project access remains available when you enable public or VPC exposure.

To enable VPC access after the ingress is ready:

1. Open Network → Settings in the addon menu.

2. If TLS is disabled, enable Deploy with TLS.

3. Select VPC under Accessibility.

4. If you also change TLS, click Update & restart. Otherwise, click Update.

5. Open Network → Connection details to use the updated endpoints and connection strings.

Clients with VPC connectivity can connect without public exposure. Clients without that connectivity can use [local forwarding](#access-a-database-locally).

## Access a database locally

You can forward a database for local access using the [Northflank CLI](https://northflank.com/docs/v1/api/use-the-cli).

Your database must be running in order to access it.

You can view and copy the command to connect to a specific database on its overview, in the local access section, or use the following commands:

- To forward a specific database:

`sudo northflank forward addon --projectId [project-name] --addonId [addon-name]`

- To forward all ports in a project:

`sudo northflank forward all --projectId [project-name]`
You can now connect to your database locally using the relevant connection strings or secrets from the connection details page.

> [!note]
>
> You may need to provide the URI in quotation marks if you are connecting via a shell command using an addon's URI connection string.

## Set IP policy rules

Open Network → Settings in the addon menu. In Security rules, click Edit security rules to set IP policies.

An IP policy restricts incoming traffic by source address. An allow rule for `192.168.1.48` permits that address. An allow rule for `192.168.1.0/24` permits addresses in that range.

Without IP policies, Northflank does not restrict connection attempts by source IP on public or VPC ingress. VPC clients also need network connectivity to the VPC.

## Access TLS certificates in containers

Your container's file system will likely already have root certificates for Certificate Authorities included, depending on the base image it was built with. You may need to provide this location via environment variable, or other configuration options, to your service or job to enable TLS connections with your Northflank addons.

You can check if your container's image contains the default certificate store by [opening a container's shell](https://northflank.com/docs/v1/application/run/access-running-containers-locally#execute-commands-in-a-container) and searching for `ISRG_Root_X1.pem` (Let's Encrypt root cert) or `ca-certificates.crt` in your container's CA path.

If the default certificate store is not present, or does not contain the required certificates, you can [download the Certificate Authority root cert](https://letsencrypt.org/certificates/) `isrgrootx1` and provide it as [a secret file](https://northflank.com/docs/v1/application/secure/upload-secret-files).

Alternatively, if your image includes a package manager, you can include an entrypoint or startup script that installs and updates the certificate store. For example:

| Base image | CA path | Update command |
| --- | --- | --- |
| Debian/Ubuntu | `/etc/ssl/certs` | `apt-get update && apt-get install -y ca-certificates && update-ca-certificates` |
| Alpine Linux | `/etc/ssl/certs` | `apk add --no-cache ca-certificates && update-ca-certificates` |
| RHEL/CentOS | `/etc/pki/tls/certs` | `yum install -y ca-certificates && update-ca-trust force-enable && update-ca-trust extract` |

## Next steps

- [Use the Northflank CLI: Learn how to create and manage projects on Northflank using the command line client.](/v1/api/use-the-cli)
- [Scale a database: Increase the storage size, number of replicas, and the available CPU and memory to improve availability and performance.](/v1/application/databases-and-persistence/scale-a-database)