# Generating a Token

To use Seal's artifact server you must first generate an access token.

1. Click on the **Settings** button and open the **Tokens** tab.
2. Click on **Create new token** at the top right of the screen.
3. Give your token a name.
4. Select the token type - either *Production* or *Development*. For more information see below.
5. Choose the expiration of your token. Since this token only allows you to download artifacts from the Seal Server, and doesn't allow you to change anything in the state of your tenant, it is recommended to set the token to never expire.
6. Click **Create token**.
7. The token will appear to you on the screen. Copy it, because you'll need it to configure access to the artifact server.

{% hint style="warning" %}
The access token will appear on the screen just once. There's no way to recover it. In general, it's recommended to save the token in a secret manager. If you lose your token, you will have to generate a new one from scratch.
{% endhint %}

<figure><img src="https://2109738374-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FytkIsVkwVdKiLQ2CT6Sw%2Fuploads%2FgqsEqxQLG1Jb9V3SYirz%2Fimage.png?alt=media&#x26;token=2b932d1d-c135-4389-9e36-0c041ec34872" alt=""><figcaption></figcaption></figure>

## Production and Development tokens

The platform supports two types of tokens - *Production* and *Development*.

Both token types allow access to the Seal artifact server. However by default, the platform only shows the activities done using *Production* tokens. *Development* tokens allow you to run the CLI and access the artifact server without raising security alerts in the platform.

#### When should you use a Development token?

In any scenario where you need access to Seal's artifact server, but where the activity shouldn't be reflected in your security dashboards. For example:

1. A developer setting up their own local environment. You should give your developers a *Development* token so they'll be able to recreate the exact same component that runs in the production environment.
2. When running the CI pipeline for a branch that isn't your main branch. For example, the CI pipeline for feature branches should in general run with a *Development* token since they don't reflect the state of the production code.

In summary, *Production* tokens should only be used on your main CI pipeline. Otherwise development activities might be reflected in the Protection page alerts and various reports.