Mirrors/unleash.unleash
1
0
Fork 0
mirror of https://github.com/Unleash/unleash.git synced 2025-08-18 13:48:58 +02:00
Code Issues Projects Releases Wiki Activity

docs: update self-hosting guide (#9855)

Browse Source
This commit is contained in:
Melinda Fekete 2025-05-05 15:57:17 +02:00 committed by GitHub
parent c0e30deafb
commit 7ca79c1b84
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
21 changed files with 534 additions and 1265 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
frontend/src/component/releases/ReleasePlanTemplate/TemplateForm/MilestoneStrategy/ReleasePlanTemplateAddStrategyForm.tsx
View File

@ -255,7 +255,7 @@ export const ReleasePlanTemplateAddStrategyForm = ({
predefined strategies like Gradual rollout with{' '}
<Link
href={
'https://docs.getunleash.io/reference/strategy-constraints'
'https://docs.getunleash.io/reference/activation-strategies#constraints'
}
target='_blank'
variant='body2'

2
src/lib/openapi/spec/validate-password-schema.ts
View File

@ -6,7 +6,7 @@ export const validatePasswordSchema = {
additionalProperties: false,
required: ['password'],
description:
'Used to validate passwords obeying [Unleash password guidelines](https://docs.getunleash.io/reference/deploy/securing-unleash#password-requirements)',
'Used to validate passwords obeying [Unleash password guidelines](https://docs.getunleash.io/using-unleash/deploy/configuring-unleash#securing-unleash)',
properties: {
password: {
description: 'The password to validate',

2
src/lib/routes/auth/reset-password-controller.ts
View File

@ -103,7 +103,7 @@ class ResetPasswordController extends Controller {
tags: ['Auth'],
summary: 'Validates password',
description:
'Verifies that the password adheres to the [Unleash password guidelines](https://docs.getunleash.io/reference/deploy/securing-unleash#password-requirements)',
'Verifies that the password adheres to the [Unleash password guidelines](https://docs.getunleash.io/using-unleash/deploy/configuring-unleash#securing-unleash)',
operationId: 'validatePassword',
requestBody: createRequestSchema('validatePasswordSchema'),
responses: {

10
website/docs/feature-flag-tutorials/use-cases/scaling-unleash.mdx
View File

@ -52,7 +52,7 @@ How you set up Unleash to scale depends significantly on the [hosting option](/u
- **How it works**: You deploy, manage, and scale all Unleash components (Unleash API server, database, [Admin UI](/understanding-unleash/unleash-overview#the-unleash-admin-ui), [Unleash Edge](/reference/unleash-edge)) within your own infrastructure (cloud or on-premises).
- **Ideal for**: Organizations with strict regulatory environments requiring full data and infrastructure control, air-gapped networks, or those with strong preferences and capabilities for managing their own software infrastructure.
- **Scaling and infrastructure**: You are responsible for architecting for high availability (for example, Multi-AZ API deployment, database clusters), scaling [compute resources](/using-unleash/deploy/configuring-unleash#minimum-and-recommended-specifications), [database capacity planning](/using-unleash/deploy/database-setup#sizing), backups, disaster recovery strategies, monitoring, handling upgrades of Unleash and Unleash Edge and other and security updates.
- **Scaling and infrastructure**: You are responsible for architecting for high availability (for example, Multi-AZ API deployment, database clusters), scaling [compute resources and database capacity planning](/using-unleash/deploy/configuring-unleash#resource-recommendations), backups, disaster recovery strategies, monitoring, handling upgrades of Unleash and Unleash Edge and other and security updates.
- **Key tradeoff**: Maximum control over data and infrastructure, at the cost of significant SRE/DevOps expertise, resources, and ongoing operational effort.
</TabItem>
@ -79,7 +79,7 @@ Utilize Auto Scaling Groups (ASGs) or similar mechanisms in cloud environments t
### Database
A [PostgreSQL database](/using-unleash/deploy/database-setup#requirements) that stores all configurations, feature flags, strategies, context fields, metrics, and audit logs. It is the critical stateful component.
A [PostgreSQL database](/using-unleash/deploy/configuring-unleash#resource-recommendations) that stores all configurations, feature flags, strategies, context fields, metrics, and audit logs. It is the critical stateful component.
The database layer must be performant and highly available. Use managed database services (such as AWS RDS for PostgreSQL) configured for high availability and backups.
@ -144,7 +144,7 @@ Key benefits:
Scale the number of Unleash API instances horizontally (by increasing the replica count behind a load balancer) or vertically (by increasing the CPU and memory limits and requests per instance) based on observed bottlenecks and traffic patterns.
Read more details in the [Unleash deployment and self-hosting guides](/using-unleash/deploy).
Read more details in the [Unleash deployment and self-hosting guides](/using-unleash/deploy/getting-started).
</details>
@ -167,7 +167,7 @@ Configure the following:
Scale the database instance vertically (to a larger instance size) or horizontally (by adding read replicas) based on observed bottlenecks.
Read more details in the [self-hosting guide](/using-unleash/deploy).
Read more details in the [self-hosting guide](/using-unleash/deploy/getting-started).
</details>
@ -175,7 +175,7 @@ Configure the following:
SDK caching provides resilience against temporary database unavailability for flag evaluations, but we still recommend that you configure high-availability for the database to maintain key functionality like flag configuration updates and Admin UI access.
Configure automatic failover for your database (managed services typically handle this). Failover within a region should ideally complete in less than a few minutes. Ensure full database backups are regularly taken and stored securely, preferably in a separate region.
Configure automatic failover for your database (managed services typically handle this). Failover within a region should ideally complete in less than a few minutes. Ensure [full database backups](/using-unleash/deploy/configuring-unleash#back-up-and-restore-the-database) are regularly taken and stored securely, preferably in a separate region.
In the rare event of a complete primary region failure (disaster recovery scenario):
1. Promote the database read replica (or restore from backup) in the standby region to become the new primary database.

2
website/docs/how-to/how-to-enable-openapi.mdx
View File

@ -78,7 +78,7 @@ docker run \
The configuration option for enabling OpenAPI and the swagger UI is `enableOAS`. Set this option to `true`.
The following examples have been shortened to show only the relevant configuration options. For more detailed instructions on how to run Unleash or the proxy, refer to [how to run the Unleash proxy](how-to-run-the-unleash-proxy.mdx) or the [section on running Unleash via Node.js from the deployment section](/using-unleash/deploy/getting-started.md#option-three---from-nodejs) of the documentation.
The following examples have been shortened to show only the relevant configuration options. For more detailed instructions, refer to [our self-hosting guide](/using-unleash/deploy/getting-started).
<Tabs groupId="openapi-configuration">

2
website/docs/quickstart.mdx
View File

@ -18,7 +18,7 @@ To start Unleash locally, clone the Unleash repository and start the server with
git clone git@github.com:Unleash/unleash.git
cd unleash
docker compose -f docker-compose-enterprise.yml up
docker compose -f docker-compose-enterprise.yml up -d
```
This pulls the `unleashorg/unleash-enterprise` Docker image and uses a Docker Compose file to configure the Unleash server and its database.

2
website/docs/reference/segments.mdx
View File

@ -52,7 +52,7 @@ In theory, you could create segments with a thousand constraints, each with a mi
By default, you can apply **at most 5 segments to any one strategy**. Separate strategies (even on the same feature) do not count towards the same total, so you can have two strategies with 5 segments each.
You **can** [configure segment limits](/using-unleash/deploy/configuring-unleash#segments) with environment variables.
You **can** [configure segment limits](/reference/resource-limits) with environment variables.
### A note on large segments {#large-segments}

2
website/docs/using-unleash/compliance/soc2.mdx
View File

@ -25,7 +25,7 @@ This guide provides an overview of how [Unleash Enterprise](https://www.getunlea
| CC 5.3, CC 7.1, CC 8.1 Change management procedures enforced | Change management procedures are enforced. | Unleash supports defining custom roles with configurable permissions in each environment. [Change Requests](/reference/change-requests) supports a 4-eyes approval workflow for changes. |
| CC 6.1, CC 8.1 Production deployment and application access restricted | The company restricts access to migrate changes to production to authorized personnel. | Unleash supports defining custom roles with configurable permissions in each environment. [Change Requests](/reference/change-requests) supports a 4-eyes approval workflow for changes. |
| CC 6.1 Unique account authentication enforced | The company requires authentication to systems and applications to use unique username and password or authorized Secure Socket Shell (SSH) keys. | Unleash supports both username/password authentication, as well as [single sign-on](/reference/sso). In addition, the [SCIM integration](/reference/scim) facilitates user account provisioning. |
| CC 6.1 Password policy enforced | The company requires passwords for in-scope system components to be configured according to the company's policy. | Unleash has [password strength requirements](/using-unleash/deploy/securing-unleash#password-requirements) for all users using username/password authentication. |
| CC 6.1 Password policy enforced | The company requires passwords for in-scope system components to be configured according to the company's policy. | Unleash has [password strength requirements](/using-unleash/deploy/configuring-unleash#password-requirements) for all users using username/password authentication. |
| CC 6.1, CC 6.6 Remote access MFA enforced | The company's production systems can only be remotely accessed by authorized employees possessing a valid multi-factor authentication (MFA) method. | You can enable MFA through your identity provider, such as Okta or Microsoft Entra ID, after implementing [single sign-on](/reference/sso). |
| CC 6.1, CC 6.6 Remote access encrypted and enforced | The company's production systems can only be remotely accessed by authorized employees via an approved encrypted connection. | Unleash is secured by enforcing TLS 1.2. |
| CC 6.7 Data transmission encrypted | The company uses secure data transmission protocols to encrypt confidential and sensitive data when transmitted over public networks. | Unleash is secured by enforcing TLS 1.2. |

735
website/docs/using-unleash/deploy/configuring-unleash.mdx
View File

@ -1,562 +1,297 @@
---
title: Configuring Unleash
title: Configure Unleash
description: "Steps and options for configuring your self-hosted Unleash instance."
toc_max_heading_level: 3
---
import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem';
> This is the guide on how to configure **Unleash v5 self-hosted**.
This guide explains how to configure your self-hosted Unleash instance when running it via [Docker Compose or the Docker CLI](/using-unleash/deploy/getting-started).
## Must configure
When running Unleash using Docker, configuration is managed through environment variables.
### Database
## Configuration method
### Docker Compose
In order for Unleash server to work, you need a running database and its connection details. See
the [database configuration section](#database-configuration) for the available options and configuration details.
## Nice to configure
### Unleash URL {#unleash-url}
- Configured with `UNLEASH_URL` ** Should be set to the public discoverable URL of your instance, so if your instance is
accessed by your users at `https://unleash.mysite.com` use that. ** If you're deploying this to a subpath, include the
subpath in this. So `https://mysite.com/unleash` will also be correct.
- Used to create
- Reset password URLs
- Welcome link for new users
- Links in events for our Slack, Microsoft Teams and Datadog integrations
### Email server details {#email-server-details}
Used to send reset-password mails and welcome mails when onboarding new users. <br /> **NOTE** - If this is not
configured, you will not be able to allow your users to reset their own passwords.
For [more details, see here](./email-service.md)
### Minimum and recommended specifications
#### Minimum
| Resource | Request | Limit |
|----------|---------|-------|
| CPU | 250m | 500m |
| Memory | 200Mi | 400Mi |
#### Recommended
| Resource | Request | Limit |
|----------|---------|-------|
| CPU | 500m | 1000m |
| Memory | 512Mi | 1Gi |
## Further customization
In order to customize "anything" in Unleash you need to
use [Unleash from Node.js](./getting-started#option-three---from-nodejs) or start
the [docker image](./getting-started.md#option-one---use-docker) with environment variables.
```js
const unleash = require('unleash-server');
const unleashOptions = {
db: {
user: 'unleash_user',
password: 'password',
host: 'localhost',
port: 5432,
database: 'unleash',
ssl: false,
pool: {
min: 0,
max: 4,
idleTimeoutMillis: 30000,
},
},
enableRequestLogger: true,
};
unleash.start(unleashOptions);
<Tabs groupId="setup-method">
<TabItem value="docker-compose-enterprise" label="Unleash Enterprise">
Update the `environment:` section of your `docker-compose-enterprise.yml` file. For example:
```yaml
services:
unleash:
image: unleashorg/unleash-enterprise
environment:
- DATABASE_HOST=mydbhost
- DATABASE_SSL=false
# ... other service config
```
**Available Unleash options include:**
</TabItem>
- **authentication** - (object) - An object for configuring/implementing custom admin authentication
<TabItem value="docker-compose-oss" label="Unleash OSS">
Update the `environment:` section of your `docker-compose.yml` file. For example:
```yaml
services:
unleash:
image: unleashorg/unleash-server
environment:
- DATABASE_HOST=mydbhost
- DATABASE_SSL=false
# ... other service config
```
- `enableApiToken` / `AUTH_ENABLE_API_TOKEN`: `boolean` — Should unleash require API tokens for access? Defaults
to `true`.
- `type` / `AUTH_TYPE`: `string` — What kind of authentication to use. Possible values
- `open-source` - Sign in with username and password. This is the default value.
- `custom` - If implementing your own authentication hook, use this
- `demo` - Only requires an email to sign in (was default in v3)
- `none` - _Deprecated_ Turn off authentication completely. If no API token is provided towards /`api/client`
or `/api/frontend` you will receive configuration for the "default" environment. We generally recommend you
use the `demo` type for simple, insecure usage of Unleash. This auth type has many known limitations,
particularly related to personalized capabilities such as favorites.
- `customAuthHandler`: function `(app: any, config: IUnleashConfig): void` — custom express middleware handling
authentication. Used when type is set to `custom`. Can not be set via environment variables.
- `initialAdminUser`: `{ username: string, password: string} | undefined` — The initial admin username and password - Defaults to `admin` and `unleash4all`, respectively. Can be set using the `UNLEASH_DEFAULT_ADMIN_USERNAME` and `UNLEASH_DEFAULT_ADMIN_PASSWORD` environment variables.
- `initApiTokens` / `INIT_ADMIN_API_TOKENS`, `INIT_CLIENT_API_TOKENS`,
and `INIT_FRONTEND_API_TOKENS`: `ApiTokens[]` — Array of API tokens to create on startup. The tokens will only
be created if the database doesn't already contain any API tokens. Example:
</TabItem>
</Tabs>
```ts
[
{
environment: '*',
project: '*',
secret: '*:*.964a287e1b728cb5f4f3e0120df92cb5',
type: ApiTokenType.ADMIN,
username: 'some-user',
},
];
### Docker CLI
<Tabs groupId="setup-method">
<TabItem value="docker-cli-enterprise" label="Unleash Enterprise">
Use the `-e` flag in your `docker run` command. For example:
```shell
docker run -e DATABASE_HOST=mydbhost -e DATABASE_SSL=false ... unleashorg/unleash-enterprise
```
</TabItem>
<TabItem value="docker-cli-oss" label="Unleash OSS">
Use the `-e` flag in your `docker run` command. For example:
```shell
docker run -e DATABASE_HOST=mydbhost -e DATABASE_SSL=false ... unleashorg/unleash-server
```
</TabItem>
</Tabs>
## Configure the database
Unleash requires a PostgreSQL database to store its data. You must provide connection details using environment variables.
### Database environment variables
| Environment Variable | Default Value | Description |
| :------------------------------------ | :----------------- | :------------------------------------------------------------------------------------------------------------------------------------------ |
| `DATABASE_HOST` | `localhost` | Database hostname or IP address. |
| `DATABASE_PORT` | `5432` | Database port. |
| `DATABASE_NAME` | `unleash` | Name of the database Unleash should use. |
| `DATABASE_USERNAME` | `unleash_user` | Database username. |
| `DATABASE_PASSWORD` | `password` | Database password. |
| `DATABASE_SCHEMA` | `public` | Database schema Unleash should use. |
| `DATABASE_SSL` | `false` | Enables/configures SSL. Expects a stringified JSON object with SSL options. |
| `DATABASE_SSL_CA_CONFIG` | N/A | Alternative SSL config via JSON string. Requires `rejectUnauthorized`, `ca`, `cert`, `key` properties, where `ca`, `cert`, `key` values contain the certificate strings directly. |
| `DATABASE_SSL_REJECT_UNAUTHORIZED` | (varies) | Set to `false` only if using self-signed certificates. Defaults to `true` if `DATABASE_SSL_CA_FILE` is set. |
| `DATABASE_SSL_CA_FILE` | N/A | Path within the container to a valid SSL CA file in PEM format. |
| `DATABASE_SSL_CERT_FILE` | N/A | Path within the container to a valid SSL Cert file in PEM format. |
| `DATABASE_SSL_KEY_FILE` | N/A | Path within the container to a valid SSL key file in PEM format. |
| `DATABASE_POOL_MIN` | `0` | Minimum number of connections in the database pool. |
| `DATABASE_POOL_MAX` | `4` | Maximum number of connections in the database pool. |
| `DATABASE_POOL_IDLE_TIMEOUT_MS` | `30000` | Time (ms) a connection can be idle before being eligible for eviction. |
| `DATABASE_APPLICATION_NAME` | `unleash` | Application name reported to the database. |
| `DATABASE_DISABLE_MIGRATION` | `false` | Set to `true` to disable automatic database migrations on startup. |
| `DATABASE_URL` | N/A | Alternatively, provide the full database connection string (e.g., `postgres://USER:PASS@HOST:PORT/DB`). Overrides individual components. |
| `DATABASE_URL_FILE` | N/A | Path within the container to a file containing the full `DATABASE_URL` string. |
For detailed PostgreSQL SSL configuration options via environment variables, refer to the [node-postgres documentation on SSL](https://node-postgres.com/features/ssl). Ensure file paths for certificates (`DATABASE_SSL_*_FILE`) are accessible inside the running container (for example, via Docker volumes).
<details>
<summary>Troubleshooting</summary>
### Database connection issues
If you experience intermittent database connection errors or timeouts, particularly after periods of inactivity, a network component (like a firewall or load balancer) between the Unleash server and the PostgreSQL database may be closing idle TCP connections. If the network component's idle timeout is shorter than the connection pool's idle timeout (`DATABASE_POOL_IDLE_TIMEOUT_MS`), the pool may try to use a connection that the network device has already terminated.
**Solution:**
1. Determine the idle connection timeout value configured on any relevant network devices (firewalls, load balancers) between Unleash and its database.
2. Ensure the Unleash database pool idle timeout, set via the `DATABASE_POOL_IDLE_TIMEOUT_MS` environment variable (default: `30000` ms), is configured to be less than the network device's idle timeout setting. For instance, if your firewall closes idle connections after 60 seconds, consider keeping or setting `DATABASE_POOL_IDLE_TIMEOUT_MS` to `30000` (30 seconds).
</details>
### Back up and restore the database
It is highly recommended to back up your Unleash database, especially before [upgrades](/using-unleash/deploy/upgrading-unleash) or significant changes. When running PostgreSQL within a Docker container, use `docker exec` to run the standard `pg_dump` (backup) and `psql` (restore) commands inside the container.
1. **Identify container name**: Find your PostgreSQL container's name or ID (for example, using `docker ps`).
2. **Create a backup**: Run the following command on your host machine. It executes `pg_dump` inside the container and saves the output to a `.dump` file on your host.
```shell
docker exec -t <your_postgres_container_name> pg_dump --clean -U <your_db_user> -d <your_db_name> > unleash-db-$(date +%Y%m%d_%H%M%S).dump
```
The tokens can be of any API token type. Note that _admin_ tokens **must** target all environments and projects (
i.e. use `'*'` for `environments` and `project` and start the secret with `*:*.`).
You can also use the environment variables `INIT_ADMIN_API_TOKENS`, `INIT_CLIENT_API_TOKENS`,
and `INIT_FRONTEND_API_TOKENS`. All variables require a comma-separated list of API tokens to initialize (for
instance `*:*.some-random-string, *:*.some-other-token`). The tokens found
in `INIT_ADMIN_API_TOKENS`, `INIT_CLIENT_API_TOKENS`, and `INIT_FRONTEND_API_TOKENS` will be created as admin,
client, and frontend tokens respectively, and Unleash will assign usernames automatically.
- `demoAllowAdminLogin` / `AUTH_DEMO_ALLOW_ADMIN_LOGIN`: `boolean` — Allows you to log in as the admin user when running Unleash with the `demo` auth type. To log in as the admin user, use `admin` as your email. Defaults to `false`.
- **databaseUrl** - (_deprecated_) the postgres database url to connect to. Only used if _db_ object is not specified,
and overrides the _db_ object and any environment variables that change parts of it (like `DATABASE_SSL`). Should
include username/password. This value may also be set via the `DATABASE_URL` environment variable. Alternatively, if
you would like to read the database url from a file, you may set the `DATABASE_URL_FILE` environment variable with the
full file path. The contents of the file must be the database url exactly.
- **db** - The database configuration object. See [the database configuration section](#database-configuration) for a
full overview of the available properties.
- **disableLegacyFeaturesApi** (boolean) - whether to disable
the [legacy features API](/reference/api/legacy/unleash/admin/features.md). Defaults
to `false` (`DISABLE_LEGACY_FEATURES_API`). Introduced in Unleash 4.6.
- **email** - the email object configuring an SMTP server for sending welcome mails and password reset mails
- `host` - The server URL to your SMTP server
- `port` - Which port the SMTP server is running on. Defaults to 465 (Secure SMTP)
- `secure` (boolean) - Whether to use SMTPS or not.
- `sender` - Which email should be set as sender of mails being sent from Unleash?
- `smtpuser` - Username for your SMTP server
- `smtppass` - Password for your SMTP server
- ~~eventHook~~ (`function(event, data)`) - (_deprecated in Unleash 4.3_ in favor of
the [Webhook integration](/reference/integrations/webhook.md). **Removed in Unleash 5**) If provided, this function
will be invoked whenever a feature is mutated. The possible values for `event`
are `'feature-created'`, `'feature-archived'` and `'feature-revived'`. The `data` argument contains information about
the mutation. Its fields are `type` (string) - the event type (same as `event`); `createdBy` (string) - the user who
performed the mutation; `data` - the contents of the change. The contents in `data` differs based on the event type;
For `'feature-archived'` and `'feature-revived'`, the only field will be `name` - the name of the feature.
For `'feature-created'` the data follows a schema defined in the
code [here](https://github.com/Unleash/unleash/blob/7b7f0b84e8cddd5880dcf29c231672113224b9a7/src/lib/schema/feature-schema.ts#L77).
See an [api here](/reference/api/legacy/unleash/admin/events).
- **getLogger** (function) - Used to register a [custom log provider](#how-do-i-configure-the-log-output).
- **logLevel** (`debug` | `info` | `warn` | `error` | `fatal`) - The lowest level to log at, also configurable using
environment variable `LOG_LEVEL`.
- **enableRequestLogger** (boolean) - use this to enable logging for requested urls and response codes (default: false).
- **preHook** (function) - this is a hook if you need to provide any middlewares to express before `unleash` adds any.
Express app instance is injected as first argument.
- **preRouterHook** (function) - use this to register custom express middlewares before the `unleash` specific routers
are added.
- **secureHeaders** (boolean) - use this to enable security headers (HSTS, CSP, etc) when serving Unleash from HTTPS.
Can also be configured through the environment variable `SECURE_HEADERS`.
- **additionalCspAllowedDomains** (CspAllowedDomains) - use this when you want to enable security headers but have
additional domains you need to allow traffic to. You can set the following environment variables:
- `CSP_ALLOWED_DEFAULT` to allow new defaultSrc (comma separated list)
- `CSP_ALLOWED_FONT` to allow new fontSrc (comma separated list)
- `CSP_ALLOWED_STYLE` to allow new styleSrc (comma separated list)
- `CSP_ALLOWED_SCRIPT` to allow new scriptSrc (comma separated list)
- `CSP_ALLOWED_IMG` to allow new imgSrc (comma separated list)
- `CSP_ALLOWED_CONNECT` to allow new connectSrc (comma separated list)
- `CSP_ALLOWED_FRAME` to allow new frameSrc (comma separated listed)
- `CSP_ALLOWED_MEDIA` to allow new mediaSrc (comma separated list)
- `CSP_ALLOWED_OBJECT` to allow new objectSrc (comma separated list)
- **server** - The server config object taking the following properties
- _port_ - which port the unleash-server should bind to. If port is omitted or is 0, the operating system will
assign an arbitrary unused port. Will be ignored if pipe is specified. This value may also be set via
the `HTTP_PORT` environment variable
- _host_ - which host the unleash-server should bind to. If host is omitted, the server will accept connections on
the unspecified IPv6 address (::) when IPv6 is available, or the unspecified IPv4 address (0.0.0.0) otherwise.
This value may also be set via the `HTTP_HOST` environment variable
- _pipe_ - parameter to identify IPC endpoints.
See https://nodejs.org/api/net.html#net_identifying_paths_for_ipc_connections for more details
- _serverMetrics_ (boolean) - use this option to turn on/off prometheus metrics.
- _baseUriPath_ (string) - use to register a base path for all routes on the application. For
example `/my/unleash/base` (note the starting /). Defaults to `/`. Can also be configured through the environment
variable `BASE_URI_PATH`.
- _unleashUrl_ (string) - Used to specify the official URL this instance of Unleash can be accessed at for an end
user. Can also be configured through the environment variable `UNLEASH_URL`.
- _gracefulShutdownEnable_: (boolean) - Used to control if Unleash should shutdown gracefully (close connections,
stop tasks,). Defaults to true. `GRACEFUL_SHUTDOWN_ENABLE`
- _gracefulShutdownTimeout_: (number) - Used to control the timeout, in milliseconds, for shutdown Unleash
gracefully. Will kill all connections regardless if this timeout is exceeded. Defaults to
1000ms `GRACEFUL_SHUTDOWN_TIMEOUT`
- _enableScheduledCreatedByMigration_: (boolean) - Schedules migrations that fills the field created_by_user_id for
past events and features. It does it gradually in chunks and runs every 15 minutes so it doesn't affect the
application's performance. Defaults to false. **NOTE:** If your installation started with Unleash v5.8 or later,
you should not need this flag! `ENABLE_SCHEDULED_CREATED_BY_MIGRATION`
- **session** - The session config object takes the following options:
- _ttlHours_ (number) - The number of hours a user session is allowed to live before a new sign-in is required.
Defaults to 48 hours. `SESSION_TTL_HOURS`
- _clearSiteDataOnLogout_ (boolean) - When `true`, a logout action will return a Clear Site Data response header
instructing the browser to clear all cookies on the same domain Unleash is running on. If disabled unleash will
only destroy and clear the session cookie. Defaults to _true_. `SESSION_CLEAR_SITE_DATA_ON_LOGOUT`
- _cookieName_ - Name of the cookies used to hold the session id. Defaults to 'unleash-session'.
- _maxParallelSessions_ - The maximum number of parallel user sessions with password based login. `MAX_PARALLEL_SESSIONS`
- **ui** (object) - Set of UI specific overrides. You may set the following keys: `environment`, `slogan`.
- **versionCheck** - the object deciding where to check for latest version
- `url` - The url to check version (Defaults to `https://version.unleash.run`) - Overridable
with (`UNLEASH_VERSION_URL`)
- `enable` - Whether version checking is enabled (defaults to true) - Overridable with (`CHECK_VERSION`) (if
anything other than `true`, does not check)
- **environmentEnableOverrides** - A list of environment names to force enable at startup. This is feature should be
used with caution. When passed a list, this will enable each environment in that list and disable all other
environments. You can't use this to disable all environments, passing an empty list will do nothing. If one of the
given environments is not already enabled on startup then it will also enable projects and toggles for that
environment. Note that if one of the passed environments doesn't already exist this will do nothing aside from log a
warning.
- **clientFeatureCaching** - configuring memoization of the /api/client/features endpoint
- `enabled` - set to true by default - Overridable with (`CLIENT_FEATURE_CACHING_ENABLED`)
- `maxAge` - the time to cache features, set to 600 milliseconds by default - Overridable
with (`CLIENT_FEATURE_CACHING_MAXAGE`) ) (accepts milliseconds)
- **frontendApi** - Configuration options for the [Unleash front-end API](/reference/front-end-api.md).
- `refreshIntervalInMs` - how often (in milliseconds) front-end clients should refresh their data from the cache.
Overridable with the `FRONTEND_API_REFRESH_INTERVAL_MS` environment variable.
- **accessControlMaxAge** - You can configure the max-age of the Access-Control-Max-Age header. Defaults to 86400
seconds. Overridable with the `ACCESS_CONTROL_MAX_AGE` environment variable.
- **responseTimeWithAppNameKillSwitch** - use this to disable metrics with app names. This is enabled by default but may
increase the cardinality of metrics causing Unleash memory usage to grow if your app name is randomly generated (which
is not recommended). Overridable with the `UNLEASH_RESPONSE_TIME_WITH_APP_NAME_KILL_SWITCH` environment variable.
- **disableCompression** - Disables Express compression middleware, useful when configuring the application in a
serverless environment. Defaults to `false`. Overridable with the `SERVER_DISABLE_COMPRESSION` environment variable.
- **keepAliveTimeout** - Use this to tweak connection keepalive timeout in seconds. Useful for hosted situations where
you need to make sure your connections are closed before terminating the instance. Defaults to `15`. Overridable with
the `SERVER_KEEPALIVE_TIMEOUT` environment variable.
You can also set the environment variable `ENABLED_ENVIRONMENTS` to a comma delimited string of environment names to
override environments.
- **metricsRateLimiting** - Use the following to tweak the rate limits
for `/api/client/register`, `/api/client/metrics`, `/api/frontend/register` and `/api/frontend/metrics` POST endpoints
- `clientMetricsMaxPerMinute` - How many requests per minute per IP is allowed against POST `/api/client/metrics`
before returning 429. Set to 6000 by default (100rps) - Overridable with `REGISTER_CLIENT_RATE_LIMIT_PER_MINUTE`
environment variable
- `clientRegisterMaxPerMinute` - How many requests per minute per IP is allowed against POST `/api/client/register`
before returning 429. Set to 6000 by default (100rps) - Overridable with `CLIENT_METRICS_RATE_LIMIT_PER_MINUTE`
environment variable
- `frontendMetricsMaxPerMinute` - How many requests per minute per IP is allowed against
POST `/api/frontend/metrics` before returning 429. Set to 6000 by default (100rps) - Overridable
with `FRONTEND_METRICS_RATE_LIMIT_PER_MINUTE` environment variable
- `frontendRegisterMaxPerMinute` - How many requests per minute per IP is allowed against
POST `/api/frontend/register` before returning 429. Set to 6000 by default (100rps) - Overridable
with `REGISTER_FRONTEND_RATE_LIMIT_PER_MINUTE` environment variable
- **rateLimiting** - Use the following to tweak the rate limits for `POST /auth/simple` (Password-based login)
and `POST /api/admin/user-admin` (Creating users)
- `simpleLoginMaxPerMinute` - How many requests per minute per IP is allowed against POST `/auth/simple` before
returning 429. Set to 10 by default - Overridable with `SIMPLE_LOGIN_LIMIT_PER_MINUTE` environment variable
- `createUserMaxPerMinute` - How many requests per minute per IP is allowed against POST `/api/admin/user-admin`
before returning 429. Set to 20 by default - Overridable with `CREATE_USER_RATE_LIMIT_PER_MINUTE` environment
variable
### Disabling Auto-Start {#disabling-auto-start}
If you're using Unleash as part of a larger express app, you can disable the automatic server start by
calling `server.create`. It takes the same options as `server.start`, but will not begin listening for connections.
```js
const express = require('express');
const unleash = require('unleash-server');
const app = express();
const start = async () => {
const instance = await unleash.create({
databaseUrl: 'postgres://unleash_user:password@localhost:5432/unleash',
});
app.use(instance.app);
console.log(`Unleash app generated and attached to parent application`);
};
start();
```
### Graceful shutdown {#shutdown-unleash}
> PS! Unleash will listen for the `SIGINT` signal and automatically trigger graceful shutdown of Unleash.
If you need to stop Unleash (close database connections, and stop running Unleash tasks) you may use the stop function.
Be aware that it is not possible to restart the Unleash instance after stopping it, but you can create a new instance of
Unleash.
```js
const express = require('express');
const unleash = require('unleash-server');
const app = express();
const start = async () => {
const instance = await unleash.start({
databaseUrl: 'postgres://unleash_user:password@localhost:5432/unleash',
port: 4242,
});
//Sometime later
await instance.stop();
console.log('Unleash has now stopped');
};
start();
```
### Segment limits {#segments}
:::caution
Changing segment limits could have a negative impact on the performance of Unleash SDKs and cause network congestion.
Think twice before changing these values.
:::
Some facets of the [segments feature](/reference/segments.mdx) can be customized via environment variables. This lets
you change the [segment limits](/reference/segments.mdx#segment-limits) that Unleash uses.
`UNLEASH_STRATEGY_SEGMENTS_LIMIT` controls the maximum number of segments that can be applied to a single strategy. The
default is 5.
`UNLEASH_SEGMENT_VALUES_LIMIT` controls the maximum number of values that you can assign across a segment's constraints.
The default is 1000 (Since v5.1.0; it was 100 before v5.1.0)
## Securing Unleash {#securing-unleash}
You can integrate Unleash with your authentication provider (OAuth 2.0). Read more
about [securing unleash](./securing-unleash.md).
## How do I configure the log output? {#how-do-i-configure-the-log-output}
By default, `unleash` uses [log4js](https://github.com/nomiddlename/log4js-node) to log important information. It is
possible to swap out the logger provider (only when using Unleash programmatically). You do this by providing an
implementation of the **getLogger** function as This enables filtering of log levels and easy redirection of output
streams.
```javascript
function getLogger(name) {
// do something with the name
return {
debug: console.log,
info: console.log,
warn: console.log,
error: console.error,
};
}
```
The logger interface with its `debug`, `info`, `warn` and `error` methods expects format string support as seen
in `debug` or the JavaScript `console` object. Many commonly used logging implementations cover this API, e.g., bunyan,
pino or winston.
## Database configuration
:::info
In-code configuration values take precedence over environment values: If you provide a database username both via
environment variables and in code with the Unleash options object, Unleash will use the in-code username.
:::
You cannot run the Unleash server without a database. You must provide Unleash with database connection details for it
to start correctly.
The available options are listed in the table below. Options can be specified either via JavaScript (only when starting
Unleash via code) or via environment variables. The "property name" column below gives the name of the property on the
Unleash options' `db` object.
| Property name | Environment variable | Default value | Description |
|--------------------------|------------------------------------|--------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `user` | `DATABASE_USERNAME` | `unleash_user` | The database username. |
| `password` | `DATABASE_PASSWORD` | `password` | The database password. |
| `host` | `DATABASE_HOST` | `localhost` | The database hostname. |
| `port` | `DATABASE_PORT` | `5432` | The database port. |
| `database` | `DATABASE_NAME` | `unleash` | The name of the database. |
| `ssl` | `DATABASE_SSL` | N/A | An object describing SSL options. In code, provide a regular JavaScript object. When using the environment variable, provide a **stringified JSON object**. |
| | `DATABASE_SSL_CA_CONFIG` | N/A | JSON file representing the SSL options, needs 4 keys set, `rejectUnauthorized`, `ca`, `cert`, `key`. the `ca`, `cert` and `key` keys needs to be ssl certificates as a string. |
| | `DATABASE_SSL_CA_FILE` | N/A | A path to a valid SSL CA file in `pem` format. Sets the `ca` key of the ssl object. See [https://node-postgres.com/features/ssl](pg docs) |
| | `DATABASE_SSL_CERT_FILE` | N/A | A path to a valid SSL Cert file in `pem` format. Sets the `cert` key of the ssl object. See [https://node-postgres.com/features/ssl](pg docs) |
| | `DATABASE_SSL_KEY_FILE` | N/A | A path to a valid SSL key file in `pem` format. Sets the `key` key of the ssl object. See [https://node-postgres.com/features/ssl](pg docs) |
| | `DATABASE_SSL_REJECT_UNAUTHORIZED` | true if CA, CERT and KEY is set, false otherwise | If you use SSL connections to postgres, don't set this to false. It will turn off the security check of SSL. See [https://node-postgres.com/features/ssl](pg docs) |
| `pool` | N/A (use the below variables) | | An object describing database pool options. With environment variables, use the options below directly. |
| `pool.min` | `DATABASE_POOL_MIN` | 0 | The minimum number of connections in the connection pool. |
| `pool.max` | `DATABASE_POOL_MAX` | 4 | The maximum number of connections in the connection pool. |
| `pool.idleTimeoutMillis` | `DATABASE_POOL_IDLE_TIMEOUT_MS` | 30000 | The amount of time (in milliseconds) that a connection must be idle for before it is marked as a candidate for eviction. |
| `applicationName` | `DATABASE_APPLICATION_NAME` | `unleash` | The name of the application that created this Client instance. |
| `schema` | `DATABASE_SCHEMA` | `public` | The schema to use in the database. |
| `disableMigration` | `DATABASE_DISABLE_MIGRATION` | false | The option not to use database migration. |
Alternatively, you can use a
single-host [libpq connection string](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING) to
connect to the database. You can provide it directly or from a file by using one of the below options. In JavaScript,
these are top-level properties of the root configuration object, _not_ the `db` object.
| Property name | Environment variable | Default value | Description |
|-------------------|----------------------|---------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `databaseUrl` | `DATABASE_URL` | N/A | A string that matches a single-host [libpq connection string](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING), such as `postgres://USER:PASSWORD@HOST:PORT/DATABASE`. Unleash does **not** support using multiple hosts. |
| `databaseUrlFile` | `DATABASE_URL_FILE` | N/A | The path to a file that contains a [libpq connection string](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING). |
Below is an example JavaScript configuration object.
3. **Restore from backup**: Run the following command on your host machine. It executes `psql` inside the container, reading the specified backup file from your host.
```js
const unleashOptions = {
databaseUrl: 'postgres:/USER:PASSWORD@HOST:PORT/DATABASE',
databaseUrlFile: '/path/to/file',
db: {
user: 'unleash_user',
password: 'password',
host: 'localhost',
port: 5432,
database: 'unleash',
ssl: false,
pool: {
min: 0,
max: 4,
idleTimeoutMillis: 30000,
},
},
};
```
```shell
docker exec -i <your_postgres_container_name> psql -U <your_db_user> -d <your_db_name> < <your_backup_file.dump>
```
### `db.ssl` vs `DATABASE_SSL` options
### Enable self-signed certificates
When initializing Unleash from code, you'll provide the `db.ssl` option as a JavaScript object. As such, any functions
will get evaluated before the object is used for configuration. When using the `DATABASE_SSL` environment variable, you
must provide the value as a stringified JSON object. The object will get parsed before being used for configuration, but
no further evaluation will take place.
To connect to a PostgreSQL database using a self-signed certificate, you need to:
- Set the `DATABASE_SSL_REJECT_UNAUTHORIZED` environment variable to `false`. Disabling this check bypasses validation that the server certificate is signed by a trusted CA; only use this when you fully trust the network path and the server identity.
- Provide the self-signed certificate itself as the Certificate Authority (CA) for Unleash to trust. Use either the `DATABASE_SSL_CA_FILE` variable (pointing to the certificate file mounted inside the container) or include the certificate string within the JSON object passed to `DATABASE_SSL_CA_CONFIG`.
If you want to read content from a file, you should either initialize Unleash via JavaScript or manually interpolate the
required values into the environment variable:
## Configure the Unleash instance URL
<Tabs groupId="db-configuration-options">
Set the public URL where your Unleash instance can be accessed using the environment variable `UNLEASH_URL`. For example, `https://unleash.mycompany.com` or `https://app.mycompany.com/unleash`. This URL is used for creating password reset links, signup links for new users, and links within integrations, such as Slack or Datadog.
<TabItem value="js" label="JavaScript" default>
## Configure an email server
```js title="Reading from the file system in JavaScript"
const unleashOptions = {
db: {
// other options omitted for brevity
ssl: {
ca: fs.readFileSync('/path/to/server-certificates/root.crt').toString(),
},
},
};
```
Configure an SMTP server to enable password resets and user welcome emails. If not configured, self-service password resets will not be available.
</TabItem>
| Environment variable | Default value | Description |
| :------------------- | :----------------------------- | :--------------------------------------------------------------------------------- |
| `EMAIL_HOST` | N/A | Your SMTP server address. |
| `EMAIL_PORT` | `587` | Your SMTP server port. |
| `EMAIL_SECURE` | `false` | Set to `true` to use SMTPS (SSL). |
| `EMAIL_USER` | N/A | The username to authenticate against your SMTP server. |
| `EMAIL_PASSWORD` | N/A | The password for your SMTP user. |
| `EMAIL_SENDER` | `noreply@unleash-hosted.com` | The email address used as the sender. Must be updated to your own address to work correctly. |
<TabItem value="env" label="Environment variables (bash)">
```bash title="Reading from the file system with bash"
DATABASE_SSL="{ \"ca\": \"$(cat /path/to/server-certificates/root.crt)\" }"
```
<details>
<summary>Troubleshooting</summary>
</TabItem>
If emails fail to send or contain errors:
</Tabs>
- **Verify configuration:** Double-check all `EMAIL_*` environment variables are correctly set for your SMTP provider.
- **Check email links:** Ensure `UNLEASH_URL` is the complete public URL for your instance, including the `http://` or `https://` protocol prefix.
- **Fix SSL/TLS errors:**
* Confirm `EMAIL_PORT` and `EMAIL_SECURE` match your SMTP server's requirements (for example, port 587 or 465 often requires `EMAIL_SECURE=true`).
- **Custom CA certificates for SMTP:** If using a custom SMTP CA certificate with `EMAIL_SECURE=true`, ensure it's trusted by mounting the PEM file into the container and setting the `NODE_EXTRA_CA_CERTS` environment variable to its path inside the container.
### Enabling self-signed certificates
</details>
To use self-signed certificates, you should set the SSL property `rejectUnauthorized` to `false` and set the `ca`
property to the value of the certificate:
## Other configuration options
<Tabs groupId="db-configuration-options">
### Authentication and authorization
<TabItem value="js" label="JavaScript" default>
| Environment Variable | Default Value | Description |
| :------------------------------ | :-------------- | :------------------------------------------------------------------------------------------------------------------------------- |
| `AUTH_TYPE` | `open-source` | Authentication type. `open-source`: sign in with username and password, `demo`: sign in with email only, `custom`: sign in using custom authentication hook. |
| `AUTH_ENABLE_API_TOKEN` | `true` | Whether API endpoints require tokens. Setting to `false` is highly discouraged. |
| `AUTH_DEMO_ALLOW_ADMIN_LOGIN` | `false` | Allows logging in as `admin` (using email field) when `AUTH_TYPE` is `demo`. |
```js title="Enable self-signed certificates"
const unleashOptions = {
db: {
// other options omitted for brevity
ssl: {
rejectUnauthorized: false,
ca: fs.readFileSync('/path/to/server-certificates/root.crt').toString(),
},
},
};
```
### Initial setup
</TabItem>
| Environment Variable | Default Value | Description |
| :--------------------------------- | :-------------- | :--------------------------------------------------------------------------------------------------------- |
| `UNLEASH_DEFAULT_ADMIN_USERNAME` | `admin` | Sets the username for the initial admin user created on first startup. |
| `UNLEASH_DEFAULT_ADMIN_PASSWORD` | `unleash4all` | Sets the password for the initial admin user. **Change this for any non-local setup.** |
| `INIT_CLIENT_API_TOKENS` | N/A | Comma-separated list of [Client tokens](/reference/api-tokens-and-client-keys#client-tokens) to create on first startup (if no tokens exist in the database). |
| `INIT_FRONTEND_API_TOKENS` | N/A | Comma-separated list of [Frontend tokens](/reference/api-tokens-and-client-keys#frontend-tokens) to create on first startup (if no tokens exist in the database). |
<TabItem value="env" label="Environment variables (bash)">
### Server behavior
```bash title="Enable self-signed certificates"
DATABASE_SSL="{ \"rejectUnauthorized\": false, \"ca\": \"$(cat /path/to/server-certificates/root.crt)\" }"
```
| Environment Variable | Default Value | Description |
| :------------------------------- | :------------ | :--------------------------------------------------------------------------------------------- |
| `HTTP_PORT` | `4242` | Port the Unleash server listens on inside the container. |
| `HTTP_HOST` | `0.0.0.0` | Host the Unleash server binds to inside the container. |
| `BASE_URI_PATH` | `/` | Sets a base path for all Unleash routes (e.g., `/unleash`). Must start with `/` if not root. |
| `CDN_PREFIX` | N/A | URL prefix for static UI assets, enabling serving from a CDN. Example: https://mycdn.com/unleash-assets. |
| `SERVER_KEEPALIVE_TIMEOUT` | `15` | Connection keepalive timeout in seconds. |
| `SERVER_DISABLE_COMPRESSION` | `false` | Set to `true` to disable response compression, useful when configuring the application in a serverless environment. |
| `GRACEFUL_SHUTDOWN_ENABLE` | `true` | Enables graceful shutdown on receiving `SIGINT` or `SIGTERM`. |
| `GRACEFUL_SHUTDOWN_TIMEOUT` | `1000` | Timeout in milliseconds for graceful shutdown before forceful exit. |
| `ENABLE_SCHEDULED_CREATED_BY_MIGRATION` | `false` | Set to `true` to enable gradual backfilling of historical `created_by_user_id` data. Only needed up until Unleash v5.8. |
</TabItem>
### Security and sessions
</Tabs>
| Environment Variable | Default Value | Description |
| :------------------------------------ | :------------------ | :--------------------------------------------------------------------------------------------------------------- |
| `SECURE_HEADERS` | `false` | Set to `true` to enable security headers like HSTS, CSP (recommended if serving over HTTPS). |
| `CSP_ALLOWED_*` | N/A | Comma-separated lists for specific [CSP directives](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy#directives) when `SECURE_HEADERS` is true. For example: `CSP_ALLOWED_SCRIPT` for `script-src`. |
| `SESSION_TTL_HOURS` | `48` | User session duration in hours. |
| `SESSION_CLEAR_SITE_DATA_ON_LOGOUT` | `true` | Whether to send `Clear-Site-Data` header on logout. | |
| `MAX_PARALLEL_SESSIONS` | N/A | Maximum number of parallel user sessions allowed with password-based login. |
| `UNLEASH_FRONTEND_API_ORIGINS` | `*` | Comma-separated list of allowed origins (CORS) for the Frontend API. Use * with caution. Example: https://app.mycompany.com,https://*.yourdomain.net.|
Visit [the node-postgres library's SSL section](https://node-postgres.com/features/ssl) for more information.
### Supported Postgres SSL modes
### Logging and monitoring
Unleash builds directly on the [node-postgres library](https://node-postgres.com/features/ssl), so we support all the
same SSL modes that they support. As of version 8 (released on February 25th
2020), [node-postgres no longer supports all sslmodes](https://node-postgres.com/announcements#2020-02-25). For this
reason, Unleash cannot support all of Postgres' SSL modes. Specifically, Unleash **does not support** `sslmode=prefer`.
Instead you must know whether you require an SSL connection ahead of time.
| Environment Variable | Default Value | Description |
| :------------------------------------------------ | :------------ | :----------------------------------------------------------------------------------------------------------------------- |
| `LOG_LEVEL` | `info` | The minimum log level (`debug`, `info`, `warn`, `error`, `fatal`). |
| `REQUEST_LOGGER_ENABLE` | `false` | Set to `true` to enable logging of incoming request URLs and response codes. |
| `UNLEASH_RESPONSE_TIME_WITH_APP_NAME_KILL_SWITCH` | `false` | Set to `true` to disable including the `appName` property in response time metrics (reduces cardinality if `appName` is variable). |
| `DAILY_METRICS_STORAGE_DAYS` | `91` | Number of days to retain aggregated daily metrics data. |
### Recommended PostgreSQL spec
### Feature and API behavior
For PostgreSQL we recommend running with at least 1 CPU and at least 1Gi of memory, as well as at least 5Gi of SSD storage. From the cloud providers, look at:
| Environment Variable | Default Value | Description |
| :--------------------------------------- | :-------------------------- | :------------------------------------------------------------------------------------------------------- |
| `CHECK_VERSION` | `true` | If the automatic check for new Unleash versions is enabled. Set to `false` to disable. |
| `UNLEASH_VERSION_URL` | `https://version.unleash.run` | Overrides the URL used for version checks. |
| `CLIENT_FEATURE_CACHING_ENABLED` | `true` | Toggles server-side memoization for `/api/client/features`. |
| `CLIENT_FEATURE_CACHING_MAXAGE` | `600` | Cache duration in milliseconds for `/api/client/features` memoization. |
| `FRONTEND_API_REFRESH_INTERVAL_MS` | N/A | Default refresh interval in milliseconds for frontend SDKs to refresh their data from the cache. |
| `ACCESS_CONTROL_MAX_AGE` | `86400` | Configures the `Access-Control-Max-Age` CORS header in seconds. |
| `ENABLED_ENVIRONMENTS` | N/A | Comma-separated list of environment names to force enable at startup, overriding the database state. Use with caution; does not disable environments not listed. |
| Provider | Machine |
|----------|--------------------------------|
| AWS | db.t4g.small (2CPU / 2GB mem) |
| Azure | B2s (2CPU / 4GB mem ) |
| GCP | 2 CPU / 4GB mem |
### Rate limiting
Unleash SAAS runs on db.t4g.small and we're happy with that.
Controls requests per minute per IP for specific API endpoints.
| Environment Variable | Default Value | Target Endpoint |
| :------------------------------------------ | :------------ | :------------------------- |
| `REGISTER_CLIENT_RATE_LIMIT_PER_MINUTE` | `6000` | POST `/api/client/register` |
| `CLIENT_METRICS_RATE_LIMIT_PER_MINUTE` | `6000` | POST `/api/client/metrics` |
| `REGISTER_FRONTEND_RATE_LIMIT_PER_MINUTE` | `6000` | POST `/api/frontend/register`|
| `FRONTEND_METRICS_RATE_LIMIT_PER_MINUTE` | `6000` | POST `/api/frontend/metrics` |
| `SIMPLE_LOGIN_LIMIT_PER_MINUTE` | `10` | POST `/auth/simple` |
| `CREATE_USER_RATE_LIMIT_PER_MINUTE` | `20` | POST `/api/admin/user-admin` |
### Troubleshooting: database pooling connection timeouts {#database-pooling-connection-timeouts}
- Check the default values of connection pool about idle session handling.
### HTTP proxy support
- If you have a network component which closes idle sessions on the TCP layer, make sure that the connection
pool's `idleTimeoutMillis` setting is lower than the `timespan` setting. If it isn't, then the network component will
close the connection.
If your Unleash server needs to make outgoing requests (for example, for integrations, webhooks, version checks) through an HTTP/HTTPS proxy, you can configure this using standard proxy environment variables.
### Troubleshooting: missing metrics from connected Edge instances
- `HTTP_PROXY`: URL of the HTTP proxy (for example, `http://proxy.mycompany.com:8080`).
- `HTTPS_PROXY`: URL of the HTTPS proxy (for example, `http://secureproxy.mycompany.com:8081`).
- `NO_PROXY`: Comma-separated list of hosts or domains that should bypass the proxy.
If you're on Unleash 5.9.0 or newer, you might encounter issues with metrics from connected Edge instances. There are
two solutions to this, the recommended way and the one that will work for 5.9.0 but probably not for later versions
Set these environment variables when starting your Unleash container.
#### Recommended
- Make sure you're using the latest Edge, at least v17.0.0
- Make sure you have at least one valid client token configured. Either using the `--token` flag on startup, or via
connecting an SDK with a valid token
## Resource recommendations
#### Works in 5.9.0
While specific minimums depend heavily on usage patterns (number of flags, frequency of requests, number of connected SDKs), a general starting point for the Unleash server container could be:
- If you absolutely cannot upgrade your Edge instances to v17.0.0 or newer you can start Unleash with the environmental
flag `UNLEASH_EXPERIMENTAL_EDGE_BULK_METRICS` set to `true`
- This will re-enable an endpoint that was disabled in 5.9.0 to allow users that cannot upgrade Edge just now to stay on
an old Edge version, but still get client metrics.
- **CPU:** 0.5 - 1 vCPU
- **Memory:** 512 MiB - 1 GiB RAM
### Proxying requests from Unleash
For the PostgreSQL database, consider:
You can configure proxy services that intercept all outgoing requests from Unleash. This lets you use the Microsoft
Teams or the Webhook integration for external services, even if the internet can only be reached via a proxy on your
machine or container (for example if restricted by a firewall or similiar).
- **CPU:** At least 1 vCPU
- **Memory:** At least 1 GiB RAM
- **Storage:** At least 5 GiB SSD storage
As an example, here's how you could do it using the [node-global-proxy](https://www.npmjs.com/package/node-global-proxy)
package:
For example, you might consider some of the following managed PostgreSQL services and machine types:
```
const proxy = require("node-global-proxy").default;
- **AWS RDS for PostgreSQL:** `db.t4g.small` (2 vCPU / 2 GiB RAM).
- **Azure Database for PostgreSQL (Flexible Server):** `B2s` (Burstable, 2 vCPU / 4 GiB RAM).
- **GCP Cloud SQL for PostgreSQL:** `db-n1-standard-1` (1 vCPU / 3.75 GiB RAM) as the starting point.
proxy.setConfig({
http: "http://user:password@url:8080", //proxy adress, replace values as needed
//https: "https://user:password@url:1080", //if a https proxy is needed
});
Monitor resource usage and adjust based on your specific load.
proxy.start(); //this starts the proxy, after this call all requests will be proxied
```
## Next steps
Using above code-snippet, every outgoing request from unleash or its integrations will be subsequently routed through
set proxy. If the proxy routing needs to be bypassed or stopped, its possible to stop it by using
### Securing Unleash
### Password requirements
By default, Unleash uses password-based login. When using passwords, Unleash enforces strong passwords:
- Minimum 10 characters long
- Contains at least one uppercase letter
- Contains at least one number
- Contains at least one special character
### Configure SSO and access controls
To learn more about managing users, [implementing single sign-on](/reference/sso) instead of passwords, setting up access controls, and using audit logs, read the [User Management, Access Controls and Auditing guide](/feature-flag-tutorials/use-cases/user-management-access-controls-auditing).
### Scaling Unleash
As your feature flag usage grows, ensuring your Unleash setup can handle the load is crucial. To learn how to implement high availability, improve resilience, and apply other scaling strategies, read the [Scaling Unleash guide](/feature-flag-tutorials/use-cases/scaling-unleash).
`proxy.stop();`

18
website/docs/using-unleash/deploy/database-backup.md
View File

@ -1,18 +0,0 @@
---
title: Database Backup
---
When upgrading to a new major version of Unleash, we advise to do a full database backup to ease rollback in case of failures.
1. Create a database backup:
```
pg_dump --clean -U unleash_user -W -h localhost unleash > unleash-db.dump
```
2. Restore from a backup:
```
psql -U unleash_user -W -h localhost unleash < unleash-db.dump
```

23
website/docs/using-unleash/deploy/database-setup.md
View File

@ -1,23 +0,0 @@
---
title: Database Setup
---
To run Unleash you need to have PostgreSQL v13.0+.
1. Create a local unleash databases in PostgreSQL
```bash
$ psql postgres <<SQL
CREATE USER unleash_user WITH PASSWORD 'password';
CREATE DATABASE unleash;
GRANT ALL PRIVILEGES ON DATABASE unleash to unleash_user;
SQL
```
You will now have a PostgreSQL database with the following configuration:
- database name: `unleash`
- username: `unleash_user`
- password: `password`
- host: `localhost` (assuming you started it locally)
- port: `5432` (assuming you are using the default PostgreSQL port)

58
website/docs/using-unleash/deploy/email-service.md
View File

@ -1,58 +0,0 @@
---
title: Email Service
---
:::note Availability
**Version**: `4.0+`
:::
Email service allows you to send password reset and welcome emails to new users. For this to work you'll need to tell Unleash what SMTP service you'd like to send emails from.
If the service is not configured you'll see a log line every time you add a new user saying
```bash
[2021-05-07T12:59:04.572] [WARN] routes/user-controller.ts - email
was not sent to the user because email configuration is lacking
```
## Configuring {#configuring}
Depending on your deploy case there are different ways of configuring this service. Full documentation of all configuration possibilities is available [here](./configuring-unleash).
### Docker {#docker}
With docker, we configure the mail service via environment variables.
You'll want to at least include EMAIL_HOST, EMAIL_USER, EMAIL_PASSWORD and EMAIL_SENDER
Environment variables:
- EMAIL_HOST - Your SMTP server address
- EMAIL_PORT - Your SMTP server port - defaults to 567
- EMAIL_SECURE - whether to use SMTPS - set to `false` or `true` - defaults to false,
- EMAIL_USER - the username to authenticate against your SMTP server
- EMAIL_PASSWORD - the password for your SMTP user
- EMAIL_SENDER - which address should reset-password mails and welcome mails be sent from - defaults to `noreply@unleash-hosted.com` which is probably not what you want.
### Node {#node}
With node, we can configure this when calling Unleash's start method.
```js
const unleash = require('unleash-server');
unleash.start({
email: {
host: 'myhost',
smtpuser: 'username',
smtppass: 'password',
sender: 'noreply@mycompany.com',
},
});
```
## Troubleshooting {#troubleshooting}
For troubleshooting tips, please refer to the [email service troubleshooting guide](../troubleshooting/email-service.md).

275
website/docs/using-unleash/deploy/getting-started.md
View File

@ -1,150 +1,185 @@
---
title: Getting Started
title: Getting started
description: "Initial steps for setting up a self-hosted Unleash instance with Docker."
toc_max_heading_level: 3
pagination_next: using-unleash/deploy/configuring-unleash
---
> This section only applies if you plan to self-host Unleash. If you are looking for our hosted solution you should head over to [www.getunleash.io](https://www.getunleash.io/plans)
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
## Requirements {#requirements}
Unleash offers several [hosting options](/understanding-unleash/hosting-options), including fully self-hosted setups. This guide helps you set up Unleash Open Source or Unleash Enterprise in your own environment using Docker.
You will need:
Alternatively, for Unleash Enterprise, you can sign up for a [cloud-hosted instance](https://www.getunleash.io/pricing).
- [Node.js](https://nodejs.org/en/download/) v18.0+
- [PostgreSQL](https://www.postgresql.org/download/) v13.0+
- [Create an unleash user and database](./database-setup).
You can set up Unleash in your environment using two main approaches with Docker:
## Start Unleash server {#start-unleash-server}
- **Docker Compose:** This method relies on a Docker Compose file to define and manage the Unleash server and its database, simplifying the setup and startup process.
- **Docker CLI:** This method gives you more direct control by using individual `docker` commands to set up the network and run the Unleash and database containers separately.
Whichever option you choose to start Unleash, you must specify a database URI (it can be set in the environment variable DATABASE_URL). If your database server is not set up to support SSL you'll also need to set the environment variable `DATABASE_SSL` to `false`
## Start Unleash server
---
### Using Docker Compose
Once the server has started, you will see the message:
To start the Unleash server, clone the Unleash repository and start the server with [Docker Compose](https://docs.docker.com/compose/):
```sh
Unleash started on http://localhost:4242
<Tabs groupId="setup-method">
<TabItem value="enterprise" label="Enterprise">
```shell
git clone git@github.com:Unleash/unleash.git
cd unleash
docker compose -f docker-compose-enterprise.yml up -d
```
To run multiple replicas of Unleash simply point all instances to the same database.
This pulls the `unleashorg/unleash-enterprise` Docker image and uses a Docker Compose file to configure the Unleash server and its database.
The first time Unleash starts it will create a default user which you can use to sign-in to you Unleash instance and add more users with:
</TabItem>
- username: `admin`
- password: `unleash4all`
<TabItem value="oss" label="Open Source">
If you'd like the default admin user to be created with a different username and password, you may define the following environment variables when running Unleash:
```shell
git clone git@github.com:Unleash/unleash.git
- `UNLEASH_DEFAULT_ADMIN_USERNAME`
- `UNLEASH_DEFAULT_ADMIN_PASSWORD`
The way of defining these variables may vary depending on how you run Unleash.
### Option 1 - use Docker {#option-one---use-docker}
**Useful links:**
- [Docker image on dockerhub](https://hub.docker.com/r/unleashorg/unleash-server/)
- [Unleash Helm Chart on artifacthub](https://artifacthub.io/packages/helm/unleash/unleash)
**Steps:**
1. Create a network by running `docker network create unleash`
2. Start a postgres database:
```sh
docker run -e POSTGRES_PASSWORD=some_password \
-e POSTGRES_USER=unleash_user -e POSTGRES_DB=unleash \
--network unleash --name postgres postgres
cd unleash
docker compose up -d
```
3. Start Unleash via docker:
This pulls the `unleashorg/unleash-server` Docker image and uses a Docker Compose file to configure the Unleash server and its database.
</TabItem>
</Tabs>
```sh
docker run -p 4242:4242 \
-e DATABASE_HOST=postgres -e DATABASE_NAME=unleash \
-e DATABASE_USERNAME=unleash_user -e DATABASE_PASSWORD=some_password \
> This step uses `docker compose` (V2 syntax). If you have the older `docker-compose` (V1), use that command syntax instead.
### Using Docker CLI
This method involves running separate containers for PostgreSQL and Unleash and connecting them manually via a Docker network.
#### Create Docker network
This allows the Unleash container to communicate with the database container by name.
```shell
docker network create unleash
```
#### Start PostgreSQL database container
This command starts a PostgreSQL container, sets up the necessary user, `unleash_user` and database `unleash`, assigns a password, and connects it to the `unleash` network.
```shell
docker run -d \
-e POSTGRES_PASSWORD=your_secure_password \
-e POSTGRES_USER=unleash_user \
-e POSTGRES_DB=unleash \
--network unleash \
--name postgres \
postgres:15 # or any 13+ version
```
#### Start Unleash server container
This command starts the Unleash server, maps port `4242` on your host to the container, connects to the PostgreSQL database you started, disables database SSL, connects to the `unleash` network, and ensures you have the latest image.
<Tabs groupId="setup-method">
<TabItem value="oss" label="Open Source">
```shell
docker run -d -p 4242:4242 \
-e DATABASE_HOST=postgres \
-e DATABASE_NAME=unleash \
-e DATABASE_USERNAME=unleash_user \
-e DATABASE_PASSWORD=your_secure_password \
-e DATABASE_SSL=false \
--network unleash --pull=always unleashorg/unleash-server
--network unleash \
--name unleash \
--pull=always \
unleashorg/unleash-server
```
### Option 2 - use Docker-compose {#option-two---use-docker-compose}
</TabItem>
**Steps:**
1. Clone the [Unleash repository](https://github.com/Unleash/unleash).
2. Run `docker compose up -d` in repository root folder.
### Option 3 - from Node.js {#option-three---from-nodejs}
1. Create a new folder/directory on your development computer.
2. From a terminal/bash shell, install the dependencies:
```shell npm2yarn
npm init
npm install unleash-server --save
```
3. Create a file called _server.js_, paste the following into it and save.
```js
const unleash = require('unleash-server');
unleash
.start({
db: {
ssl: false,
host: 'localhost',
port: 5432,
database: 'unleash',
user: 'unleash_user',
password: 'password',
},
server: {
port: 4242,
},
})
.then((unleash) => {
console.log(
`Unleash started on http://localhost:${unleash.app.get('port')}`,
);
});
```
4. Run _server.js_:
```sh
node server.js
```
## Create an api token for your client {#create-an-api-token-for-your-client}
- [Create an API token](/reference/api-tokens-and-client-keys#create-an-api-token).
## Test your server and create a sample API call {#test-your-server-and-create-a-sample-api-call}
Once the Unleash server has started, go to [localhost:4242](http://localhost:4242) in your browser. If you see an empty list of feature flags, try creating one with [curl](https://curl.se/) from a terminal/bash shell:
<TabItem value="enterprise" label="Enterprise">
```shell
docker run -d -p 4242:4242 \
-e DATABASE_HOST=postgres \
-e DATABASE_NAME=unleash \
-e DATABASE_USERNAME=unleash_user \
-e DATABASE_PASSWORD=your_secure_password \
-e DATABASE_SSL=false \
--network unleash \
--name unleash \
--pull=always \
unleashorg/unleash-enterprise
```
curl --location -H "Authorization: <apitoken from previous step>" \
--request POST 'http://localhost:4242/api/admin/features' \
--header 'Content-Type: application/json' --data-raw '{\
"name": "Feature.A",\
"description": "Dolor sit amet.",\
"type": "release",\
"enabled": false,\
"stale": false,\
"strategies": [\
{\
"name": "default",\
"parameters": {}\
}\
]\
</TabItem>
</Tabs>
## Log in to the Unleash Admin UI
<Tabs groupId="setup-method">
<TabItem value="oss" label="Open Source">
In your browser, go to [http://localhost:4242](http://localhost:4242) and log in using the following credentials:
- **username**: `admin`
- **password**: `unleash4all`
![Unleash Admin UI log in screen](/img/quickstart-login.png)
The first time Unleash starts, it creates this default `admin` user. To use different credentials for the initial admin user, set the following environment variables before starting the Unleash container for the first time:
- `UNLEASH_DEFAULT_ADMIN_USERNAME=<your_custom_username>`
- `UNLEASH_DEFAULT_ADMIN_PASSWORD=<your_custom_secure_password>`
</TabItem>
<TabItem value="enterprise" label="Enterprise">
In your browser, go to [http://localhost:4242](http://localhost:4242) and log in using the following credentials:
- **username**: `admin`
- **password**: `unleash4all`
![Unleash Admin UI log in screen](/img/quickstart-login.png)
The first time Unleash starts, it creates this default `admin` user. To use different credentials for the initial admin user, set the following environment variables before starting the Unleash container for the first time:
- `UNLEASH_DEFAULT_ADMIN_USERNAME=<your_custom_username>`
- `UNLEASH_DEFAULT_ADMIN_PASSWORD=<your_custom_secure_password>`
### Install your license
If you are running Unleash Enterprise, you need to install a [license key](/using-unleash/deploy/license-keys#get-a-new-license). You'll receive a license key as part of your trial or from your account representative.
In the Admin UI, go to **Admin > License**, copy the license key you received by email and click **Update license key**.
</TabItem>
</Tabs>
## Test your server connection
You can quickly test if your server is running and accepting API requests using `curl`. For example, you can attempt creating a feature flag via the [Admin API](/understanding-unleash/unleash-overview#admin-api). Replace `<API_TOKEN>` with a valid [API token](/reference/api-tokens-and-client-keys) and adjust the URL `http://localhost:4242` if needed.
```shell
curl --location --request POST 'http://localhost:4242/api/admin/features' \
--header 'Authorization: <API_TOKEN>' \
--header 'Content-Type: application/json' \
--data-raw '{
"name": "Test Feature Flag",
"description": "Feature flag for testing",
"type": "release",
"enabled": false,
"stale": false,
"strategies": [
{
"name": "default",
"parameters": {}
}
]
}'
```
## Version check {#version-check}
## Disable version check
- Unleash checks that it uses the latest version by making a call to https://version.unleash.run.
- This is a cloud function storing instance id to our database for statistics.
- This request includes a unique instance id for your server.
- If you do not wish to check for upgrades define the environment variable `CHECK_VERSION` to anything else other than `true` before starting, and Unleash won't make any calls
- `export CHECK_VERSION=false`
By default, your self-hosted Unleash instance periodically checks https://version.unleash.run to inform you about new releases. This check sends a unique, anonymous instance ID.
If you prefer to disable this version check, set the environment variable `CHECK_VERSION` to `false` before starting the Unleash server.

260
website/docs/using-unleash/deploy/google-auth-hook.md
View File

@ -1,260 +0,0 @@
---
title: Google Auth Hook
---
> You can also find the complete [source code for this guide](https://github.com/Unleash/unleash-examples/tree/main/v4/securing-google-auth) in the unleash-examples project.
This part of the tutorial shows how to create a sign-in flow for users and integrate with Unleash server project. The implementation assumes that I am working in `localhost` with `4242` port.
This is a simple `index.ts` server file.
```javascript
const unleash = require('unleash-server');
unleash.start(options).then((unleash) => {
console.log(`Unleash started on http://localhost:${unleash.app.get('port')}`);
});
```
### Creating a web application client ID {#creating-a-web-application-client-id}
1. Go to the credentials section in the [Google Cloud Platform Console](https://console.cloud.google.com/apis/credentials?_ga=2.77615956.-1991581217.1542834301).
2. Click **OAuth consent screen**. Type a product name. Fill in any relevant optional fields. Click **Save**.
3. Click **Create credentials > OAuth client ID**.
4. Under **Application type**, select **Web Application**.
5. Type the **Name**.
6. Under **Authorized redirect URIs** enter the following URLs, one at a time.
```
http://localhost:4242/api/auth/callback
```
7. Click **Create**.
8. Copy the **CLIENT ID** and **CLIENT SECRET** and save them for later use.
### Add dependencies {#add-dependencies}
Add two dependencies [`@passport-next/passport`](https://www.npmjs.com/package/@passport-next/passport) and [`@passport-next/passport-google-oauth2`](https://www.npmjs.com/package/@passport-next/passport-google-oauth2) inside `index.ts` file
```js
const unleash = require('unleash-server');
const passport = require('@passport-next/passport');
const GoogleOAuth2Strategy =
require('@passport-next/passport-google-oauth2').Strategy;
```
Add `googleAdminAuth()` function and other options. Make sure to also accept the services argument to get access to the `userService`.
```js
function googleAdminAuth(app, config, services) {
const { baseUriPath } = config.server;
const { userService } = services;
}
let options = {
authentication: {
type: 'custom',
customAuthHandler: googleAdminAuth,
},
};
unleash.start(options).then((instance) => {
console.log(
`Unleash started on http://localhost:${instance.app.get('port')}`,
);
});
```
### In `googleAdminAuth` function: Configure the Google strategy for use by Passport.js {#in-googleadminauth-function-configure-the-google-strategy-for-use-by-passportjs}
OAuth 2-based strategies require a `verify` function which receives the credential (`accessToken`) for accessing the Google API on the user's behalf, along with the user's profile. The function must invoke `cb` with a user object, which will be set at `req.user` in route handlers after authentication.
```js
const GOOGLE_CLIENT_ID = '...';
const GOOGLE_CLIENT_SECRET = '...';
const GOOGLE_CALLBACK_URL = 'http://localhost:4242/api/auth/callback';
function googleAdminAuth(app, config, services) {
const { baseUriPath } = config.server;
const { userService } = services;
passport.use(
new GoogleOAuth2Strategy(
{
clientID: GOOGLE_CLIENT_ID,
clientSecret: GOOGLE_CLIENT_SECRET,
callbackURL: GOOGLE_CALLBACK_URL,
},
async function (accessToken, refreshToken, profile, cb) {
// Extract the minimal profile information we need from the profile object
// and connect with Unleash
const email = profile.emails[0].value;
const user = await userService.loginUserWithoutPassword(email, true);
cb(null, user);
},
),
);
}
```
### In `googleAdminAuth` function {#in-googleadminauth-function}
Configure `passport` package.
```js
function googleAdminAuth(app, config, services) {
// ...
app.use(passport.initialize());
app.use(passport.session());
passport.serializeUser((user, done) => done(null, user));
passport.deserializeUser((user, done) => done(null, user));
// ...
}
```
Implement a preRouter hook for `/auth/google/login`. It's necessary for login with Google.
```js
function googleAdminAuth(app, config, services) {
// ...
app.get(
'/auth/google/login',
passport.authenticate('google', { scope: ['email'] }),
);
// ...
}
```
Implement a preRouter hook for `/api/auth/callback`. It's a callback when the login is executed.
```js
function googleAdminAuth(app, config, services) {
// ...
app.get(
'/api/auth/callback',
passport.authenticate('google', {
failureRedirect: '/api/admin/error-login',
}),
(req, res) => {
// Successful authentication, redirect to your app.
res.redirect('/');
},
);
// ...
}
```
Implement a preRouter hook for `/api/`.
```js
function googleAdminAuth(app, config, services) {
// ...
app.use('/api/', (req, res, next) => {
if (req.user) {
next();
} else {
// Instruct unleash-frontend to pop-up auth dialog
return res
.status('401')
.json(
new unleash.AuthenticationRequired({
path: '/auth/google/login',
type: 'custom',
message: `You have to identify yourself in order to use Unleash. Click the button and follow the instructions.`,
}),
)
.end();
}
});
// ...
}
```
### The complete code {#the-complete-code}
> You can also find the complete [source code for this guide](https://github.com/Unleash/unleash-examples/tree/main/v4/securing-google-auth) in the unleash-examples project.
The `index.ts` server file.
```js
'use strict';
const unleash = require('unleash-server');
const passport = require('@passport-next/passport');
const GoogleOAuth2Strategy = require('@passport-next/passport-google-oauth2');
const GOOGLE_CLIENT_ID = '...';
const GOOGLE_CLIENT_SECRET = '...';
const GOOGLE_CALLBACK_URL = 'http://localhost:4242/api/auth/callback';
function googleAdminAuth(app, config, services) {
const { baseUriPath } = config.server;
const { userService } = services;
passport.use(
new GoogleOAuth2Strategy(
{
clientID: GOOGLE_CLIENT_ID,
clientSecret: GOOGLE_CLIENT_SECRET,
callbackURL: GOOGLE_CALLBACK_URL,
},
async (accessToken, refreshToken, profile, cb) => {
const email = profile.emails[0].value;
const user = await userService.loginUserWithoutPassword(email, true);
cb(null, user);
},
),
);
app.use(passport.initialize());
app.use(passport.session());
passport.serializeUser((user, done) => done(null, user));
passport.deserializeUser((user, done) => done(null, user));
app.get(
'/auth/google/login',
passport.authenticate('google', { scope: ['email'] }),
);
app.get(
'/api/auth/callback',
passport.authenticate('google', {
failureRedirect: '/api/admin/error-login',
}),
(req, res) => {
res.redirect('/');
},
);
app.use('/api/', (req, res, next) => {
if (req.user) {
next();
} else {
return res
.status('401')
.json(
new unleash.AuthenticationRequired({
path: '/auth/google/login',
type: 'custom',
message: `You have to identify yourself in order to use Unleash. Click the button and follow the instructions.`,
}),
)
.end();
}
});
}
const options = {
authentication: {
type: 'custom',
customAuthHandler: googleAdminAuth,
},
};
unleash.start(options);
```

2
website/docs/using-unleash/deploy/license-keys.mdx
View File

@ -1,5 +1,5 @@
---
title: License Keys
title: License keys
---
:::note Availability

57
website/docs/using-unleash/deploy/securing-unleash.md
View File

@ -1,57 +0,0 @@
---
title: Securing Unleash
---
> This guide is only relevant if you are using Unleash Open-Source. The Enterprise edition does already ship with multiple SSO options, such as SAML 2.0, OpenID Connect.
Unleash Open-Source v4 comes with username/password authentication out of the box. In addition Unleash v4 also comes with API token support, to make it easy to handle access tokens for Client SDKs and programmatic access to the Unleash APIs.
### Password requirements {#password-requirements}
Unleash requires a strong password.
- minimum 10 characters long
- contains at least one uppercase letter
- contains at least one number
- contains at least one special character (symbol)
### Implementing Custom Authentication {#implementing-custom-authentication}
If you do not wish to use the built-in username/password authentication you can add a customAuthHandler
To secure the Admin API, you have to tell Unleash that you are using a custom admin authentication and implement your authentication logic as a preHook.
```javascript
const unleash = require('unleash-server');
const myCustomAdminAuth = require('./auth-hook');
unleash
.start({
databaseUrl: 'postgres://unleash_user:password@localhost:5432/unleash',
authentication: {
type: 'custom',
customAuthHandler: myCustomAdminAuth,
},
})
.then((unleash) => {
console.log(
`Unleash started on http://localhost:${unleash.app.get('port')}`,
);
});
```
Additionally, you can trigger the admin interface to prompt the user to sign in by configuring your middleware to return a `401` status on protected routes. The response body must contain a `message` and a `path` used to redirect the user to the proper login route.
```json
{
"message": "You must be logged in to use Unleash",
"path": "/custom/login"
}
```
Examples of custom authentication hooks:
- [securing-google-auth](https://github.com/Unleash/unleash-examples/tree/main/v4/securing-google-auth)
- [securing-basic-auth](https://github.com/Unleash/unleash-examples/tree/main/v4/securing-basic-auth)
- [securing-keycloak-auth](https://github.com/Unleash/unleash-examples/tree/main/v4/securing-keycloak-auth)
- [securing-azure-auth](https://github.com/Unleash/unleash-examples/tree/main/v4/securing-azure-auth)

157
website/docs/using-unleash/deploy/upgrading-unleash.mdx
View File

@ -1,109 +1,96 @@
---
title: Upgrading Unleash
title: Upgrade Unleash
description: "Migration guides and breaking changes for upgrading Unleash versions."
toc_max_heading_level: 2
---
import VideoContent from '@site/src/components/VideoContent.jsx'
Generally, the intention is that `unleash-server` should always provide support for clients one major version lower than the current one. This should make it possible to upgrade `unleash` gradually.
This guide provides recommendations for upgrading your self-hosted Unleash instance, particularly when moving between major versions using Docker deployments.
## Upgrading to v6 from v5
Unleash aims to support client SDKs connecting to a server version that is one major version newer than the client, facilitating gradual upgrades.
[Unleash v6](https://github.com/Unleash/unleash/issues/4380) was released on June 6th, 2024. **We expect this upgrade to be straightforward**, provided you have followed the previous migration guides on this page. We're removing some features that were deprecated in version 5 and marking some features as deprecated, but these will continue to be supported during version 6. Here's the list of the outstanding changes you need to take into account when migrating from v5 to v6:
Before you begin any major version upgrade, we strongly recommend performing a [full backup of your PostgreSQL database](/using-unleash/deploy/configuring-unleash#back-up-and-restore-the-database). This ensures you can restore your instance if issues occur during the upgrade.
### Self-hosted enterprise customers are now required to use a License Key
## Upgrading from v5 to v6
Before upgrading you should make sure to get a valid license key. More information in [this page](../deploy/license-keys.mdx).
[Unleash v6](https://github.com/Unleash/unleash/issues/4380), released in June 2024, introduced several key changes. Ensure you address the following before or during your upgrade to v6.
- For Unleash hosted (Pro/Enterprise), license management is not necessary and is handled automatically.
- For Unleash Open Source, no license is necessary and these steps do not apply.
### Database requirement: PostgreSQL v13+
### Remove Passport libs from the official open source Docker distribution
Unleash v6 requires **PostgreSQL version 13 or later**. Running v6 with older PostgreSQL versions (10, 11, 12) is unsupported, though the server might start with a warning message.
Plan to upgrade your PostgreSQL instance to a supported version before or alongside your Unleash upgrade.
*If you're not using the official open source image, you can safely ignore this change.*
### License key required for self-hosted Enterprise
The [official open source Docker image](https://hub.docker.com/r/unleashorg/unleash-server) no longer includes these custom authentication libraries. If you're using this feature, there is a [community image](https://github.com/Unleash/unleash-docker-community) that contains (and will continue to contain) these dependencies.
Starting with v6, self-hosted Unleash Enterprise instances require a valid license key to function. Obtain your [license key](/using-unleash/deploy/license-keys) before upgrading and ensure the license key is configured correctly.
### Drop support for PostgreSQL versions 10, 11 and 12
### Passport libraries removed from Open Source Docker distribution
*If you're using PostgreSQL 13 or above you can safely ignore this change.*
The official `unleashorg/unleash-server` Docker image for Unleash Open Source no longer includes libraries previously used for certain custom authentication methods.
Unleash v6 will output an error message when starting with an unsupported version but continue to run. We recommend upgrading to a supported version as soon as possible.
If you were relying on these libraries via a custom authentication hook built into a custom image based on the official one, your authentication will break.
### Update to Node.js version 20+
Consider migrating to [Unleash Enterprise](https://www.getunleash.io/pricing) to use [single sign-on](/reference/sso), use password-based authentication, or explore [community-maintained images](https://github.com/Unleash/unleash-docker-community) that may still include these dependencies if absolutely necessary.
Unleash v6 drops support for Node.js versions below 20, which is the [active LTS at the time of release](https://github.com/nodejs/Release/blob/6209d04302e62156b964a605f619283582334c95/README.md#release-schedule).
### API changes
### Remove /edge/metrics endpoint
- The Unleash Edge metrics endpoint `/edge/metrics` has been removed. If you use Unleash Edge, ensure your Edge instances are upgraded to **version 19.1.3 or later** before upgrading the Unleash server to v6 to maintain metrics collection. Core flag evaluation will still work with older Edge versions.
- The legacy feature endpoint `/api/feature`, [deprecated in v4](#legacy-v2-routes-removed), has been removed. Update any integrations still using this endpoint.
- Deprecated import service: The older file-based import functionality at startup has been removed. Use the current [environment import/export features](/how-to/how-to-environment-import-export) or associated APIs.
*If you're not using Unleash Edge, you can safely ignore this change.*
### Dropped Internet Explorer support
If you're using Unleash Edge to connect to Unleash, make sure to first upgrade Unleash Edge to version 19.1.3 or above. If you're using an older version of Edge, the core feature flag functionality will still work, but you will not be able to gather any metrics.
Support for Internet Explorer has been removed, aligning with upstream dependencies (React v18) and Microsoft's end-of-support for the browser.
### Remove legacy `/api/feature` endpoint
### Deprecated custom strategies
If you're still using this endpoint, check out the [deprecation notice in v4](#4-legacy-v2-routes-removed).
While still functional in v6, custom strategies are deprecated in favor of using standard strategies combined with [strategy constraints](/reference/activation-strategies#constraints).
Consider migrating if possible, as constraints offer similar flexibility without requiring custom code distribution with SDKs.
### Remove deprecated [import service](../../how-to/how-to-import-export)
### High availability upgrade considerations
Unleash v6 drops support for file based import at startup. If you're using this functionality, please check out the issue about adding this functionality to the current import service ([#7128](https://github.com/Unleash/unleash/issues/7128)).
If you run multiple Unleash instances in a high-availability setup and are upgrading from a version **below 5.6.11** directly to **version 5.7 or higher**, you might experience temporary UI unavailability during a rolling upgrade while instances with different versions (`<5.7` and `>=5.7`) are running simultaneously.
SDKs are not affected.
If you're using that endpoint for a custom integration, you should migrate to the [new import service](../../how-to/how-to-environment-import-export) ([new import/export api docs](../../reference/api/unleash/import-export)).
For a comparison between the two, refer to the [environment import/export vs instance import/export](../../how-to/how-to-environment-import-export#environment-importexport-vs-the-instance-importexport-api) section at the bottom of this page.
To avoid UI downtime, perform a two-step upgrade: first, upgrade all instances to `v5.6.11`. Once all instances are running `v5.6.11`, proceed with the upgrade to `v5.7` or later.
### Deprecate custom strategies
Downgrading from v5.7+ to versions below v5.7 is not straightforward and requires manual database intervention.
Using custom strategies has the drawback of requiring you to distribute the strategy's code with the Unleash client SDK. In contrast, [strategy constraints](../../reference/activation-strategies#constraints) function without needing additional code or maintenance. In most cases, [strategy constraints](../../reference/activation-strategies#constraints) offer sufficient control you need without added complexity.
### Requires Node.js version 20+
If you can't accomplish the same functionality with strategy constraints, please let us know about your use case on [Slack](https://slack.unleash.run/).
If you run Unleash from source or using a custom build environment (not the official Docker image), you must ensure your environment uses Node.js version 20 or later. Unleash v6 drops support for Node.js versions below 20, which is the [active LTS at the time of release](https://github.com/nodejs/Release/blob/6209d04302e62156b964a605f619283582334c95/README.md#release-schedule).
### Dropping Internet Explorer (IE) Support
## Upgrading from v4 to v5
With Unleash v6, Internet Explorer is no longer supported. React v18, used in Unleash, has dropped support for IE, aligning with Microsoft's end of support for IE on June 15, 2022. Users are encouraged to switch to modern browsers for the best experience.
## Upgrading to 5.7 and later from versions < 5.6.11
When running on high-availability (multiple Unleash instances), upgrading from versions lower than 5.6.11 to version 5.7 or higher will cause a temporary UI unavailability while old versions and new versions are both serving traffic, due to a compatibility issue. If you can afford having a small period of time with the UI unavailable (note the SDKs will not be affected), then you can safely upgrade.
If you rather want to avoid that, you should first update to 5.6.11 and ensure all your Unleash instances are running 5.6.11 before upgrading to 5.7 or later. Any Unleash instances left on earlier versions after the backing database has been updated will continue to work, but you will not be able to log in to them, but the SDKs will continue working fine.
Once you have upgraded to version 5.7 and above, you can no longer downgrade to versions before 5.7 without manual changes to the database.
## Upgrading directly from v3.x to v5.x
<VideoContent videoUrls={["https://www.youtube.com/embed/qmusq_9mE2E"]}/>
Ivar Østhus, Unleash CTO and Co-Founder, demonstrates how to update Unleash 3.x to Unleash 5.x in just a few minutes with no downtime. You can also [watch this on YouTube with a transcript](https://www.youtube.com/watch?v=qmusq_9mE2E&cc_load_policy=1).
## Upgrading from v4.x to v5.x {#upgrading-from-v4x-to-v5x}
Unleash v5 was released on April 27th, 2023. It contains a few breaking changes.
Unleash v5, released on April 27th, 2023, introduced several key changes. Ensure you address the following before or during your upgrade to v5.
### Requires Node.js version 18+
Unleash v5 drops support Node.js versions below 18, which is the current active LTS at the time of release. Unleash v4 officially supported Node.js v14 and v16, but both of these will reach end of life in 2023.
If you run Unleash from source or using a custom build environment (not the official Docker image), you must ensure your environment uses Node.js version 18 or later.
Unleash v5 drops support for Node.js versions below 18, which was the active LTS at the time of release. Unleash v4 officially supported Node.js v14 and v16, both of which reached end of life in 2023.
### The Google Authenticator provider for SSO has been removed
### The Google Authenticator provider for SSO removed
The Google Authenticator provider is now hidden by default. We recommend using [OpenID Connect](../../how-to/how-to-add-sso-open-id-connect.md) instead.
The Google Authenticator, deprecated in v4, has now been removed. Migrate to using [OpenID Connect](../../how-to/how-to-add-sso-open-id-connect.md) instead.
However, if you are running a self hosted version of Unleash and you need to temporarily re-enable Google SSO, you can do so by setting the `GOOGLE_AUTH_ENABLED` environment variable to `true`. If you're running a hosted version of Unleash, you'll need to reach out to us and ask us to re-enable the flag. However, the ability to do this will be removed in a future release and this is not safe to depend on.
If you are running a self-hosted version of Unleash and you need to temporarily re-enable the Google Authenticator SSO, you can do so by setting the `GOOGLE_AUTH_ENABLED` environment variable to `true`. If you're running a hosted version of Unleash, you'll need to contact support to request re-enabling the flag.
This provider was deprecated in v4.
### Default database password updated
### Default database password
The Unleash default database password was updated to `password`.
The Unleash default database password is now `password` instead of `passord`. Turns out that the Norwegian word for password is too similar to the English word, and that people would think it was a typo.
This change should only impact development builds and initial setup. You should never use the default password in production environments.
This should only impact dev builds and initial setup. You should never use the default password in any production environments.
### The /api/admin/features API removed
### The /api/admin/features API is gone
Most of the old features API was deprecated in v4.3 and superseded by the project API instead. In v5, the deprecated parts have been completely removed. The only operations on that API that are still active are the operations to add or remove a tag from a feature flag.
Most of the old features API was deprecated in v4.3 and superseded by the project API. In v5, the deprecated parts have been completely removed. The only operations remaining on that API path are those to add or remove a tag from a feature flag.
### Error message structure
Some of Unleash's API error messages have changed their structure. Specifically, this applies to error messages generated by our OpenAPI validation layer. However, only their structure has changed (and they now contain more human-friendly messages); the error codes should still be the same.
Some Unleash API error messages changed their structure in v5, specifically those generated by the OpenAPI validation layer. While the structure changed to provide more human-friendly messages and align with other Unleash errors, the error codes remain the same.
Previously, they would look like this:
Previously, validation errors looked like this:
``` json
{
@ -122,7 +109,7 @@ Previously, they would look like this:
}
```
Now they look like this instead, and are more in line with the rest of Unleash's error messages.
Now they look like this:
```json
{
@ -138,30 +125,34 @@ Now they look like this instead, and are more in line with the rest of Unleash's
}
```
As such, if you're relying on the specifics of the error structure for those API errors, you might need to update your handling.
If your integrations rely on the specific structure of these validation error messages, you might need to update your error handling logic.
## Upgrading from v3.x to v4.x {#upgrading-from-v3x-to-v4x}
## Upgrading from v3 to v5
Before you upgrade we strongly recommend that you take a full [database backup](database-backup), to make sure you can downgrade to version 3.
Follow along with our video demonstration on upgrading from v3 to v5 with no downtime in just a few minutes.
### 1. All API calls now require a token. {#1-all-api-calls-now-requires-token}
<VideoContent videoUrls={["https://www.youtube.com/embed/qmusq_9mE2E"]}/>
If you are upgrading from Unleash Open-Source v3 client SDKs did not need to use an API token in order to connect to Unleash-server. Starting from v4 we have back-ported the API token handling for Enterprise in to the Open-Source version. This means that all client SDKs now need to use a client token in order to connect to Unleash.
## Upgrading from v3 to v4
Read more in the [API token documentation](../../how-to/how-to-create-api-tokens.mdx).
### All API calls now require a token
### 2. Configuring Unleash {#2-configuring-unleash}
In Unleash Open Source v3, client SDKs did not require an API token to connect to the Unleash server. Starting with v4, API token handling, previously an Enterprise feature, was added to the Open Source version. This means that all client SDKs now need to use a client token to connect to Unleash.
We have done a lot of changes to the options you can pass in to Unleash. If you are manually configuring Unleash you should have a look on the updated [configuring Unleash documentation](./configuring-unleash).
Read more in the [API token documentation](../../how-to/how-to-create-api-tokens).
### 3. Role-based Access Control (RBAC) {#3-role-based-access-control-rbac}
### Configuring Unleash
We have implemented RBAC in Unleash v4. This has totally changed the permission system in Unleash.
The options for configuring Unleash changed significantly in v4. If you are manually configuring Unleash, review the updated [configuring Unleash](/using-unleash/deploy/configuring-unleash) documentation.
**Required actions:** If you have implemented "custom authentication" for your users you will need to make changes to your integration:
### Introduced role-based access control
- _extendedPermissions_ option has been removed. You can no longer specify custom permission per-user basis. All "logged_in users" must belong to a "root" role. This can be "Admin", "Editor" or "Viewer". This is taken care of when you create new users via userService.
- All "logged-in users" needs to be defined in Unleash and have a unique ID. This can be achieved by calling "createUser" on "userService".
Unleash v4 introduced role-based access control (RBAC), which significantly changed the permission system.
If you implemented custom authentication for your users, you need to make the following changes to your integration:
- The `extendedPermissions` option has been removed. You can no longer specify custom permissions on a per-user basis. All logged-in users must belong to a root role (Admin, Editor, or Viewer). This is handled when creating users via the `userService`.
- All logged-in users need to be defined in Unleash and have a unique ID. This can be achieved by calling `createUser` on the `userService`.
Code example:
@ -175,17 +166,15 @@ const user = userService.loginUserWithoutPassword(
req.session.user = user;
```
- [Read more about Securing Unleash v4](./securing-unleash.md)
- [Read more about RBAC](../../reference/rbac.md)
[Read more about RBAC in our reference documentation](/reference/rbac).
### 4. Legacy v2 routes removed {#4-legacy-v2-routes-removed}
### Legacy v2 routes removed
Only relevant if you use the `enableLegacyRoutes` option.
This is only relevant if you previously used the `enableLegacyRoutes` option.
In v2 you could query feature flags on `/api/features`. This was deprecated in v4 and we introduced two different endpoints (`/api/admin/features` and `/api/client/features`) to be able to optimize performance and security. In v3 you could still enable the legacy routes via the `enableLegacyRoutes` option. This was removed in v4.
In v2 you could query feature flags on `/api/features`. This endpoint was deprecated in v4 and we introduced two different endpoints (`/api/admin/features` and `/api/client/features`) to optimize performance and security.
In v3 you could still enable the legacy routes via the `enableLegacyRoutes` option. This was removed in v4.
### 5. Unleash CLI has been removed {#5-unleash-cli-has-been-removed}
### Unleash CLI removed
Unleash no longer ships with a binary that allows you to start Unleash directly from the command line. From v4 you need to either use Unleash via docker or programmatically.
Read more in our [getting started documentation](./getting-started.md)
Unleash no longer ships with a binary that allows you to start Unleash directly from the command line. We recommend that you run Unleash [using Docker](/using-unleash/deploy/getting-started).

35
website/docs/using-unleash/troubleshooting/email-service.md
View File

@ -1,35 +0,0 @@
---
title: The email service is not working correctly on my self-hosted Unleash instance
---
When setting up your self-hosted Unleash instance, one of the available options is to configure an [email service](https://docs.getunleash.io/using-unleash/deploy/email-service) that will allow Unleash to send reset password and welcome emails to users.
Here's how to troubleshoot some common issues related to the email service.
## Configuration
The most common issues arise from misconfiguration. Please refer to the following documentation for guidance:
- [Email service](https://docs.getunleash.io/using-unleash/deploy/email-service)
- [Configuring Unleash](https://docs.getunleash.io/using-unleash/deploy/configuring-unleash)
You should double check that the details in your configuration look correct.
## Invalid URL error
Make sure that the [UNLEASH_URL](https://docs.getunleash.io/using-unleash/deploy/configuring-unleash#unleash-url) variable is correctly set to a valid URL. This should be set to the public discoverable URL of your Unleash instance, and it should include the protocol (http or https).
Examples:
- Subdomain: `https://unleash.mysite.com`
- Subpath: `https://mysite.com/unleash`
## SSL-related errors
### SMTP TLS port
Please double check that you're trying to reach your SMTP server on the TLS port, typically `587`.
### Custom SSL certificate
If you're using your own SMTP server which uses a custom SSL certificate, you will need to tell Unleash to trust that certificate. You can do this by setting the [NODE_EXTRA_CA_CERTS](https://docs.getunleash.io/using-unleash/deploy/configuring-unleash#node-extra-ca-certs) variable to the path of the certificate file.
This is usually done by mounting the custom certificate in a volume, and then setting `NODE_EXTRA_CA_CERTS` to the absolute path in the container where it can find the certificate. For example, if you mount it to `/var/certs`, you should set `NODE_EXTRA_CA_CERTS` to something like `/var/certs/mycert.crt`.

60
website/docusaurus.config.ts
View File

@ -868,66 +868,6 @@ class="header-github-link"
from: '/how-to/how-to-troubleshoot-feature-not-available',
to: '/using-unleash/troubleshooting/feature-not-available',
},
{
from: ['/reference/deploy', '/deploy'],
to: '/using-unleash/deploy',
},
{
from: [
'/reference/deploy/getting-started',
'/deploy/getting_started',
],
to: '/using-unleash/deploy/getting-started',
},
{
from: [
'/reference/deploy/configuring-unleash',
'/deploy/configuring_unleash',
],
to: '/using-unleash/deploy/configuring-unleash',
},
{
from: [
'/reference/deploy/database-setup',
'/deploy/database-setup',
],
to: '/using-unleash/deploy/database-setup',
},
{
from: [
'/reference/deploy/database-backup',
'/deploy/database-backup',
],
to: '/using-unleash/deploy/database-backup',
},
{
from: [
'/reference/deploy/email-service',
'/deploy/email',
],
to: '/using-unleash/deploy/email-service',
},
{
from: [
'/reference/deploy/google-auth-hook',
'/deploy/google_auth',
],
to: '/using-unleash/deploy/google-auth-hook',
},
{
from: [
'/deploy/migration_guide',
'/reference/deploy/migration-guide',
],
to: '/using-unleash/deploy/upgrading-unleash',
},
{
from: [
'/reference/deploy/securing-unleash',
'/deploy/securing_unleash',
],
to: '/using-unleash/deploy/securing-unleash',
},
{
from: [
'/reference/deploy/import-export',

15
website/sidebars.ts
View File

@ -584,22 +584,14 @@ const sidebars: SidebarsConfig = {
{
type: 'category',
link: {
type: 'generated-index',
title: 'Self-Hosting Unleash',
description:
'All you need to learn how to deploy and manage your own Unleash instance.',
slug: '/using-unleash/deploy',
type: 'doc',
id: 'using-unleash/deploy/getting-started',
},
label: 'Self-hosting',
label: 'Self-hosting Unleash',
items: [
'using-unleash/deploy/getting-started',
'using-unleash/deploy/configuring-unleash',
'using-unleash/deploy/database-setup',
'using-unleash/deploy/database-backup',
'using-unleash/deploy/email-service',
'using-unleash/deploy/google-auth-hook',
'using-unleash/deploy/upgrading-unleash',
'using-unleash/deploy/securing-unleash',
'using-unleash/deploy/license-keys',
],
},
@ -690,7 +682,6 @@ const sidebars: SidebarsConfig = {
items: [
'using-unleash/troubleshooting/cors',
'using-unleash/troubleshooting/https',
'using-unleash/troubleshooting/email-service',
'using-unleash/troubleshooting/feature-not-available',
'using-unleash/troubleshooting/flag-exposure',
'using-unleash/troubleshooting/flag-not-returned',

54
website/vercel.json
View File

@ -711,6 +711,31 @@
"destination": "/understanding-unleash/hosting-options",
"permanent": true
},
{
"source": "/using-unleash/deploy",
"destination": "/using-unleash/deploy/getting-started",
"permanent": true
},
{
"source": "/using-unleash/deploy/database-backup",
"destination": "/using-unleash/deploy/configuring-unleash#configure-the-database-connection",
"permanent": true
},
{
"source": "/using-unleash/deploy/database-setup",
"destination": "/using-unleash/deploy/configuring-unleash#configure-the-database-connection",
"permanent": true
},
{
"source": "/using-unleash/deploy/email-service",
"destination": "/using-unleash/deploy/configuring-unleash#configure-an-email-server",
"permanent": true
},
{
"source": "/using-unleash/troubleshooting/email-service",
"destination": "/using-unleash/deploy/configuring-unleash#configure-an-email-server",
"permanent": true
},
{
"source": "/understanding-unleash/proxy-hosting",
"destination": "/understanding-unleash/hosting-options",
@ -778,12 +803,12 @@
},
{
"source": "/reference/deploy",
"destination": "/using-unleash/deploy",
"destination": "/using-unleash/deploy/getting-started",
"permanent": true
},
{
"source": "/deploy",
"destination": "/using-unleash/deploy",
"destination": "/using-unleash/deploy/getting-started",
"permanent": true
},
{
@ -818,42 +843,47 @@
},
{
"source": "/reference/deploy/database-setup",
"destination": "/using-unleash/deploy/database-setup",
"destination": "/using-unleash/deploy/configuring-unleash#configure-the-database-connection",
"permanent": true
},
{
"source": "/deploy/database-setup",
"destination": "/using-unleash/deploy/database-setup",
"destination": "/using-unleash/deploy/configuring-unleash#configure-the-database-connection",
"permanent": true
},
{
"source": "/reference/deploy/database-backup",
"destination": "/using-unleash/deploy/database-backup",
"destination": "/using-unleash/deploy/configuring-unleash#configure-the-database-connection",
"permanent": true
},
{
"source": "/deploy/database-backup",
"destination": "/using-unleash/deploy/database-backup",
"destination": "/using-unleash/deploy/configuring-unleash#configure-the-database-connection",
"permanent": true
},
{
"source": "/reference/deploy/email-service",
"destination": "/using-unleash/deploy/email-service",
"destination": "/using-unleash/deploy/configuring-unleash#configure-an-email-server",
"permanent": true
},
{
"source": "/deploy/email",
"destination": "/using-unleash/deploy/email-service",
"destination": "/using-unleash/deploy/configuring-unleash#configure-an-email-server",
"permanent": true
},
{
"source": "/reference/deploy/google-auth-hook",
"destination": "/using-unleash/deploy/google-auth-hook",
"destination": "/using-unleash/deploy/getting-started",
"permanent": true
},
{
"source": "/deploy/google_auth",
"destination": "/using-unleash/deploy/google-auth-hook",
"destination": "/using-unleash/deploy/getting-started",
"permanent": true
},
{
"source": "'/using-unleash/deploy/google-auth-hook",
"destination": "/using-unleash/deploy/getting-started",
"permanent": true
},
{
@ -868,12 +898,12 @@
},
{
"source": "/reference/deploy/securing-unleash",
"destination": "/using-unleash/deploy/securing-unleash",
"destination": "/using-unleash/deploy/configuring-unleash#securing-unleash",
"permanent": true
},
{
"source": "/deploy/securing_unleash",
"destination": "/using-unleash/deploy/securing-unleash",
"destination": "/using-unleash/deploy/configuring-unleash#securing-unleash",
"permanent": true
},
{