Export a JFrog CLI server configuration

A Config Token is a portable handle for a server entry. jf config export prints that token so you can import the same logical server configuration on another machine with jf config import. You need at least one configured server before exporting.

Prerequisite: At least one server must be configured. See jf config add.

This topic covers:

Export a specific server
Export the active server
Typical cross-machine workflow

Synopsis

jf config export <server-id>

Aliases: jf c ex

Where:

<server-id>: Optional. When provided, that server is exported. When omitted, the CLI exports the currently active (default) server.

Arguments

Argument	Required	Description
`server-id`	No	Export only this server. Omit to export the active server

📘
Note
When server-id is omitted, the CLI exports the active (default) server without printing its name. Run jf config show first to confirm which server is currently active.

Examples

Export a Server Configuration

To export a specific server configuration:

Run:
```
jf config export <server-id>
```
Where:
- <server-id>: The ID of the server to export.
For example:
```
jf config export my-server
```
Copy the token from stdout. A successful export prints a single-line base64 token:
```
eyJ2ZXJzaW9uIjoyLCJzZXJ2ZXJJZCI6Im15LXNlcnZlciJ9
```
Pass this token to jf config import on the target machine. For token handling rules, see jf config import.

Export the Active Server (No Argument)

To export whichever server is currently the default:

Run:
```
jf config export
```
To verify which server will be exported before running this command, use jf config show.

When to Use

Use jf config export when you need to transfer a server configuration to another machine — for example, setting up a colleague's development environment or configuring a new CI/CD agent.

🚧
Caution
On the target machine, if a server with the same ID already exists, jf config import will silently overwrite it. Back up the target machine's configuration with jf config show before importing.

Typical workflow

To copy a configuration from one machine to another:

On the source machine, capture the token:
```
TOKEN=$(jf config export <server-id>)
```
Where:
- <server-id>: The server to export.
For example:
```
TOKEN=$(jf config export my-server)
```
Transfer TOKEN through a secure channel (secrets manager, encrypted message, and so on). Do not print or log the token in CI output or shared terminals.
On the target machine, import the token. See jf config import for the exact jf config import syntax.
To verify the import on the target machine, run:
```
jf config show <server-id>
```
Where:
- <server-id>: Same logical ID as on the source (as encoded in the token).
For example:
```
jf config show my-server
```

Important Notes

Token format: The Config Token is a base64-encoded JSON reference containing the server ID. It is used by jf config import to identify and reconstruct the server entry. The token does not embed credentials directly.
Security: Do not store the Config Token in version control or share it through insecure channels. While the token itself does not contain raw credentials, it can be used to overwrite server configurations on any machine that imports it.
Omit server ID: When you omit the server ID, the currently active server is exported. The CLI does not print the server name alongside the token — use jf config show beforehand to confirm which server is active.
Overwrite risk: Importing a token on a machine that already has a server with the same ID will silently replace that configuration with no warning. Always back up the target machine's config before importing.
Credential expiry: If the server was configured with an access token or password, those credentials retain their own expiry independent of this export operation.