mirror of
https://github.com/Unleash/unleash.git
synced 2025-08-13 13:48:59 +02:00
docs: update self-hosting guide (#9855)
This commit is contained in:
parent
c0e30deafb
commit
7ca79c1b84
@ -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'
|
||||
|
@ -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',
|
||||
|
@ -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: {
|
||||
|
@ -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.
|
||||
|
@ -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">
|
||||
|
||||
|
@ -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.
|
||||
|
@ -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}
|
||||
|
||||
|
@ -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. |
|
||||
|
@ -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**.
|
||||
|
||||
## Must configure
|
||||
|
||||
### Database
|
||||
|
||||
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);
|
||||
```
|
||||
|
||||
**Available Unleash options include:**
|
||||
|
||||
- **authentication** - (object) - An object for configuring/implementing custom admin authentication
|
||||
|
||||
- `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:
|
||||
|
||||
```ts
|
||||
[
|
||||
{
|
||||
environment: '*',
|
||||
project: '*',
|
||||
secret: '*:*.964a287e1b728cb5f4f3e0120df92cb5',
|
||||
type: ApiTokenType.ADMIN,
|
||||
username: 'some-user',
|
||||
},
|
||||
];
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
```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,
|
||||
},
|
||||
},
|
||||
};
|
||||
```
|
||||
|
||||
### `db.ssl` vs `DATABASE_SSL` options
|
||||
|
||||
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.
|
||||
|
||||
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:
|
||||
|
||||
<Tabs groupId="db-configuration-options">
|
||||
|
||||
<TabItem value="js" label="JavaScript" default>
|
||||
|
||||
```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(),
|
||||
},
|
||||
},
|
||||
};
|
||||
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).
|
||||
|
||||
When running Unleash using Docker, configuration is managed through environment variables.
|
||||
|
||||
## Configuration method
|
||||
### Docker Compose
|
||||
|
||||
<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
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
|
||||
<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)\" }"
|
||||
<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
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### 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>
|
||||
|
||||
### Enabling self-signed certificates
|
||||
## Configure the database
|
||||
|
||||
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:
|
||||
Unleash requires a PostgreSQL database to store its data. You must provide connection details using environment variables.
|
||||
|
||||
<Tabs groupId="db-configuration-options">
|
||||
### Database environment variables
|
||||
|
||||
<TabItem value="js" label="JavaScript" default>
|
||||
| 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. |
|
||||
|
||||
```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(),
|
||||
},
|
||||
},
|
||||
};
|
||||
```
|
||||
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).
|
||||
|
||||
</TabItem>
|
||||
<details>
|
||||
<summary>Troubleshooting</summary>
|
||||
|
||||
<TabItem value="env" label="Environment variables (bash)">
|
||||
### Database connection issues
|
||||
|
||||
```bash title="Enable self-signed certificates"
|
||||
DATABASE_SSL="{ \"rejectUnauthorized\": false, \"ca\": \"$(cat /path/to/server-certificates/root.crt)\" }"
|
||||
```
|
||||
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.
|
||||
|
||||
</TabItem>
|
||||
**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).
|
||||
|
||||
</Tabs>
|
||||
</details>
|
||||
|
||||
Visit [the node-postgres library's SSL section](https://node-postgres.com/features/ssl) for more information.
|
||||
### Back up and restore the database
|
||||
|
||||
### Supported Postgres SSL modes
|
||||
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.
|
||||
|
||||
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.
|
||||
1. **Identify container name**: Find your PostgreSQL container's name or ID (for example, using `docker ps`).
|
||||
|
||||
### Recommended PostgreSQL spec
|
||||
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.
|
||||
|
||||
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:
|
||||
```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
|
||||
```
|
||||
|
||||
| Provider | Machine |
|
||||
|----------|--------------------------------|
|
||||
| AWS | db.t4g.small (2CPU / 2GB mem) |
|
||||
| Azure | B2s (2CPU / 4GB mem ) |
|
||||
| GCP | 2 CPU / 4GB mem |
|
||||
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.
|
||||
|
||||
Unleash SAAS runs on db.t4g.small and we're happy with that.
|
||||
```shell
|
||||
docker exec -i <your_postgres_container_name> psql -U <your_db_user> -d <your_db_name> < <your_backup_file.dump>
|
||||
```
|
||||
|
||||
### Enable self-signed certificates
|
||||
|
||||
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`.
|
||||
|
||||
## Configure the Unleash instance URL
|
||||
|
||||
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.
|
||||
|
||||
## Configure an email server
|
||||
|
||||
Configure an SMTP server to enable password resets and user welcome emails. If not configured, self-service password resets will not be available.
|
||||
|
||||
| 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. |
|
||||
|
||||
|
||||
### Troubleshooting: database pooling connection timeouts {#database-pooling-connection-timeouts}
|
||||
<details>
|
||||
<summary>Troubleshooting</summary>
|
||||
|
||||
- Check the default values of connection pool about idle session handling.
|
||||
If emails fail to send or contain errors:
|
||||
|
||||
- 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.
|
||||
- **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.
|
||||
|
||||
### Troubleshooting: missing metrics from connected Edge instances
|
||||
</details>
|
||||
|
||||
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
|
||||
## Other configuration options
|
||||
|
||||
#### Recommended
|
||||
### Authentication and authorization
|
||||
|
||||
- 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
|
||||
| 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`. |
|
||||
|
||||
#### Works in 5.9.0
|
||||
### Initial setup
|
||||
|
||||
- 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.
|
||||
| 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). |
|
||||
|
||||
### Proxying requests from Unleash
|
||||
### Server behavior
|
||||
|
||||
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).
|
||||
| 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. |
|
||||
|
||||
As an example, here's how you could do it using the [node-global-proxy](https://www.npmjs.com/package/node-global-proxy)
|
||||
package:
|
||||
### Security and sessions
|
||||
|
||||
```
|
||||
const proxy = require("node-global-proxy").default;
|
||||
| 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.|
|
||||
|
||||
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
|
||||
});
|
||||
|
||||
proxy.start(); //this starts the proxy, after this call all requests will be proxied
|
||||
```
|
||||
### Logging and monitoring
|
||||
|
||||
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
|
||||
| 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. |
|
||||
|
||||
### Feature and API behavior
|
||||
|
||||
| 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. |
|
||||
|
||||
### Rate limiting
|
||||
|
||||
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` |
|
||||
|
||||
|
||||
### HTTP proxy support
|
||||
|
||||
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.
|
||||
|
||||
- `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.
|
||||
|
||||
Set these environment variables when starting your Unleash container.
|
||||
|
||||
|
||||
## Resource recommendations
|
||||
|
||||
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:
|
||||
|
||||
- **CPU:** 0.5 - 1 vCPU
|
||||
- **Memory:** 512 MiB - 1 GiB RAM
|
||||
|
||||
For the PostgreSQL database, consider:
|
||||
|
||||
- **CPU:** At least 1 vCPU
|
||||
- **Memory:** At least 1 GiB RAM
|
||||
- **Storage:** At least 5 GiB SSD storage
|
||||
|
||||
For example, you might consider some of the following managed PostgreSQL services and machine types:
|
||||
|
||||
- **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.
|
||||
|
||||
Monitor resource usage and adjust based on your specific load.
|
||||
|
||||
## Next steps
|
||||
|
||||
### 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();`
|
||||
|
@ -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
|
||||
```
|
@ -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)
|
@ -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).
|
@ -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`
|
||||
|
||||

|
||||
|
||||
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`
|
||||
|
||||

|
||||
|
||||
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.
|
||||
|
@ -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);
|
||||
```
|
@ -1,5 +1,5 @@
|
||||
---
|
||||
title: License Keys
|
||||
title: License keys
|
||||
---
|
||||
|
||||
:::note Availability
|
||||
|
@ -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)
|
@ -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).
|
||||
|
@ -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`.
|
@ -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',
|
||||
|
@ -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',
|
||||
|
@ -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
|
||||
},
|
||||
{
|
||||
|
Loading…
Reference in New Issue
Block a user