Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -1,10 +1,13 @@
---
title: "Initial Setup"
description: "How to initialise the instance and create the first superuser."
title: 'Initial Setup'
description: 'How to initialise the instance and create the first superuser.'
sidebar_position: 10
---

The application is built using Django which comes with a handy set of admin pages available at `/admin/`. To access these, you'll need to create a superuser. This user can also be used to access the admin pages or the application itself if you have the frontend application running as well. This user can be created using the instructions below, depending on your installation:
The application is built using Django which comes with a handy set of admin pages available at `/admin/`. To access
these, you'll need to create a superuser. This user can also be used to access the admin pages or the application itself
if you have the frontend application running as well. This user can be created using the instructions below, depending
on your installation:

## Local Installation

Expand All @@ -15,14 +18,23 @@ python manage.py createsuperuser

## Cloud Environments (e.g. Heroku, ECS)

Once the app has been deployed, you can initialise your installation by accessing `/api/v1/users/config/init/`. This will show a page with a basic form to set up some initial data for the platform. Each of the parameters in the form are described below.
Once the app has been deployed, you can initialise your installation by accessing `/api/v1/users/config/init/`. This
will show a page with a basic form to set up some initial data for the platform. Each of the parameters in the form are
described below.

| Parameter name | Description |
| --------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| Username | A unique username to give the installation superuser |
| Email | The email address to give the installation superuser |
| Password | The password to give the installation superuser |
| Site name | A human-readable name for the site, e.g. 'Flagsmith' |
| Parameter name | Description |
| --------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| Username | A unique username to give the installation superuser |
| Email | The email address to give the installation superuser |
| Password | The password to give the installation superuser |
| Site name | A human-readable name for the site, e.g. 'Flagsmith' |
| Site domain[^1] | The domain that the frontend of the site will be running on, e.g. app.flagsmith.com. This will be used for e.g. password reset emails. |

[^1]: It is important that this is correct as it is used in the password reset emails to construct the reset link.
[^1]: It is important that this is correct as it is used in the password reset emails to construct the reset link.

## Automated setup

For repeatable, headless deployments — such as Docker, Kubernetes, or CI/CD pipelines — you can use
[Provisioning](/deployment-self-hosting/core-configuration/provisioning) to declaratively define users, organisations,
projects, and more in YAML files. This replaces the need for manual UI setup and is the recommended approach for
infrastructure-as-code workflows.
Loading