Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 CLI Reference | 2025.1

# p4 server

Create, modify, or delete a P4 Server specification.

## Syntax

    p4 [g-opts] server serverID
    p4 [g-opts] server -g
    p4 [g-opts] server -d serverID
    p4 [g-opts] server -o [-l] serverID
    p4 [g-opts] server -i [-c edge-server|commit-server]
    p4 [g-opts] server -c edge-server|commit-server serverID

Syntax conventions

## Description

A server specification describes the high-level configuration and intended usage of a P4 Server. For installations with only one P4 Server, the server specification is optional.

The `p4 server` command puts the server spec into a temporary file and invokes the editor configured by the `P4EDITOR` variable. Saving the file creates or saves changes to the server specification.

An operator type user cannot execute this command. To learn about user types, see Types of users.

(2019.1 and later) For a convenient way to adjust the configuration, see the DistributedConfig: field.

### Filtering

The `ClientDataFilter`, `RevisionDataFilter`, and `ArchiveDataFilter` fields are for replicated environments where you filter out unnecessary metadata. For instance, a build server does not need to replicate the have list The list of file revisions most recently synced from the depot into the workspace. In other words, the list of files that the client workspace has. for every open client workspace on the target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'.. See "Filtering metadata during replication or edge-to-edge chaining" in the P4 Server Administration Documentation.

If you change the value of the RevisionDataFilter: field, you must reseed the server.

## Form Fields

Field Name | Type | Description
--- | --- | ---
`ServerID:` | Read-only | A unique identifier for this server. This must match the contents of the server’s `server.id` file as defined by the `p4 serverid` command. (If you are using the deprecated P4NAME environment variable, make sure it matches.)
`Type:` | Writable | Server executable type. One of the following:
Type | Notes
--- | ---
server | declares a server instance
proxy | declares a P4P instance
broker | declares a P4Broker instance
connector | declares a git-connector instance
Each type can offer one or more services.
`Services:` | Writable | Services provided by a specific server type. To learn more, see Deployment architecture in the P4 Server Administration Documentation. To assign a service to a server, the administrator uses the Services field that appears with the p4 server command:
Services for server type server
Service | Description | Notes
--- | --- | ---
`standard` | standard P4 Server | In general, the server that supports directly-connected clients in a single-server environment. This is the default and does not require explicit assignment in `p4 server` form. It is also possible for a `standard` server to be the central server The one server that is innermost in a multi-server deployment. In the server specification form field for Services, the central server might be specified as “standard” or “commit-server”. If edge servers are part of the multi-server deployment, the central server must be a commit server. See also 'upstream server'. that has downstream replica servers.
`replica` | read-only replica server | Maintains copies of target server metadata and file content. Services commands that read metadata Rejects commands that would update metadata. Use with a broker. See Using P4Broker to redirect read-only commands) Enables Offline Checkpoints to prevent target server downtime for checkpoint or backup. Can be used as a warm stand-by server for disaster recovery See Configuring a read-only replica in the P4 Server Administration Documentation.
`forwarding-replica` | replica that forwards update commands | Services commands that read metadata Automatically forwards update commands to the target server See Forwarding replica in the P4 Server Administration Documentation.
`commit-server` | central server in a multi-server installation | A multi-server P4 service consists of a combination of a commit server and one or more edge servers. A commit server stores the canonical archives and permanent metadata. Similar to a central server The one server that is innermost in a multi-server deployment. In the server specification form field for Services, the central server might be specified as “standard” or “commit-server”. If edge servers are part of the multi-server deployment, the central server must be a commit server. See also 'upstream server'. that is not a commit server, but might not contain all workspace information. To learn more, see Commit-edge in the P4 Server Administration Documentation. When you create a server spec with the `Services` field set to `commit-server`, some database changes occur. For details, see P4 Schema Documentation on Upgrades. In addition, any open files with the `+l` exclusive open file type modifier cause a `db.excl` record to be created along with an associated journal record. A large number of such records might affect replication performance.
`edge-server` | node in a multi-server installation | Performance can improve if clients connect to a regional edge server that is geographically closer than the remote commit server. (See Commit-edge in the P4 Server Administration Documentation.) Geographically separated edge servers can form a chain that ultimately arrives at the commit server. Maintains a copy of commit server metadata, file content as controlled by the lbr.replication setting of the edge server, and local metadata for edge workspace "work-in-progress" data. (See the Perforce Knowledge Base article, "Edge Servers", especially the section on "p4 submit".)
`build-server` | replica that supports builder server (or build farm) integration | In addition to supporting read-only commands, allows the p4 client and p4 sync commands to be used to create clients and sync files on the build server. Supports read-only commands Also supports the p4 client and p4 sync commands to create clients and sync files on the build server. See Build server.
`standby` | read-only replica server that uses journalcopy | Same as a read-only replica except: Supports the p4 failover command for failover against mandatory servers. (See "mandatory" under Failover in the P4 Server Administration Documentation.) Uses p4 journalcopy and p4 pull -L for metadata replication. Available with 2018.2 and later servers.
`forwarding-standby` | forwarding-replica that uses journalcopy | Same as the fowarding-replica except: Supports the p4 failover command for failover against mandatory servers. Uses p4 journalcopy and p4 pull -L for metadata replication. Available with 2018.2 and later releases of P4 Server. See Failover in the P4 Server Administration Documentation.
`local` | personal server in the DVCS environment | See P4 Server Administration Documentation.
P4AUTH | server that provides central authentication | A set of independent servers can share a single server for authentication. See Centralized authorization server (P4AUTH).
P4CHANGE | server that provides central change numbers | A set of independent servers can share a single server for changelist numbers. See Centralized changelist server (P4CHANGE)
`distribution-server` | content distribution server | Server for distribution of content pushed from a source P4 Server. See Distribution Server in the P4 Server Administration Documentation.
Services for server type proxy
Service | Description | Notes
--- | --- | ---
`proxy` | P4 Proxy | Server spec required when a proxy connects to the P4 Server that is running with security level 6. See P4 Proxy.
Services for server type broker
Service | Description | Notes
--- | --- | ---
`broker` | P4 Broker | Server spec required when a broker connects to the P4 Server that is running with security level 6. See P4 Broker.
Services for server type connector
Service | Description | Notes
--- | --- | ---
`git-connector` | P4 Git Connector intermediary server for Git to P4 | Mirrors, caches, or replicates Git repositories. See Working with Git.
For additional details, see: How replica types handle requests. The Perforce Knowledge Base article, Replica Types and Use Cases.
Options: | Writable | mandatory: A standby or forwarding-standby server that persists journalcopy'ed metadata before that metadata is replicated to other replicas. A standby or forwarding-standby server with this option set can be used for failover whether or not the server from which it is journalcopy'ing is available at the time of the failover. nomandatory: (default) Replication to other replicas can occur before the metadata has been persisted by this standby or forwarding-standby server. Failover can occur to this standby or forwarding-standby server only if the server from which it is journalcopy'ing is available at the time of the failover. This field is relevant to standby and forwarding-standby servers and is ignored by other types of servers.
ReplicatingFrom: | Writable | Server ID of the server from which this server is replicating or journalcopy'ing. This field is required when the server is a standby or forwarding-standby server and the mandatory option is set for either. If you want a forwarding replica to offload read-only commands from an edge server, set this field in the forwarding replica's server spec to the server ID of the edge server.
`Name:` | Writable | Leave this blank or set it to the same value as the `serverid`.
`Address:` | Writable | The `P4PORT` used by this server. Commit and edge servers require this field if you want to use p4 reload in this way: `p4 reload -c client-name -p serverID`
`ExternalAddress:` | Writable | This field contains the external address the commit server uses to connect to the edge server. Set to the P4PORT used during the commit-edge setup to create the service user login ticket from the commit server to the edge server. If the edge server uses SSL/TLS, the port must include the `ssl` prefix, where `ssl:443` could be an example. This field is required for parallel submit in a multi-server environment. For example: `tokyo-edge.your-company.com:1666` Prior to 2019.2, for a Git Connector server, this optional field could contain a list of repos to be updated, with a space before each repo name. Beginning in 2019.2, UpdateCachedRepos is the field to use for this purpose.
`UpdateCachedRepos:` | Writable | Beginning in 2019.2, this optional field can contain a list of repos to be updated, with each repo name on a separate line. See the Upgrading Git Connector and Configuring Git Connector to Poll Repos topics in Work with Git in P4 Server Administration Documentation.
`Description:` | Writable | An optional description for this server. For example,
     Description:
        Created by maria
`User:` | Writable | The service user name used by the server. For additional information about the use of this field, see the section on "Service users" in the P4 Server Administration Documentation.
`AllowedAddresses:` | Writable | A list of addresses that are valid this server. At security level 6, this field is used to associate intermediary servers with specified service users. Connections through intermediary servers without matching server specs will be blocked.
`ClientDataFilter:` | Writable | For a replica server, this optional field can contain one or more patterns describing how active client workspace metadata is to be filtered. Active client workspace metadata includes have lists, working records, and pending resolves. To include active client metadata, use the syntax: `//client-pattern/...` To exclude active client metadata, use the syntax: `-//client-pattern/...` All patterns are specified in client syntax. Changes only come into effect after the replica or edge server has been restarted.
`RevisionDataFilter:` | Writable | For a replica server, this optional field can contain one or more patterns describing how submitted revision metadata is to be filtered. Submitted revision metadata includes revision records, integration records, label contents, and the files listed in submitted changelists. To include submitted revision depot metadata, use the syntax: `//depot/pattern/...` To exclude submitted revision depot metadata, use the syntax: `-//depot/pattern/...` All patterns are specified in depot syntax. You must reseed the server if you change the `RevisionDataFilter` filter, and changes only come into effect after the replica or edge server has been restarted.
`ArchiveDataFilter:` | Writable | For a replica server, this optional field can contain one or more patterns describing the policy for automatically scheduling the replication of file content. If this field is present, only those files described by the pattern are automatically transferred to the replica. Other files are not transferred until they are referenced by a replica command that needs the file content. Files specified in the `ArchiveDataFilter` field are transferred to the replica regardless of whether any users of the replica have made requests for their content. To automatically transfer files on submit, use the syntax: `//depot/pattern/...` To exclude files from automatic transfer, use the syntax: `-//depot/pattern/...` All patterns are specified in depot syntax. If you want to include most depot paths, use this pattern:
    //...
    -//depot/projA/...
    -//depot/projB/...
which begins by including all paths. If you want to include only a few specific depot paths, use this pattern:
    //depot/projA/...
    //depot/projB/...
which implicitly excludes all paths that are not explicitly included. Changes to filters only come into effect after the replica or edge server has been restarted.
`DistributedConfig:` | Writable | For all server types, this field shows a line for each configurable that is set to a non-default value. In this field, the admin can edit certain values, add a new line to set certain configurables to a non-default value, or delete a line to reset certain configurables to their default value. For example,
    DistributedConfig:
      P4TARGET=host7:1234
      track=1
Note that: The commit server's any# values, for example, any#monitor=2, apply throughout the multi-server environment, unless overridden locally. This server's local values, for example, monitor=3, override the any# values. When creating a new Edge or Commit server, this optional field is displayed only when you use the -c option. This option causes the configuration values to be populated with currently configured values, recommended default values (if unset), or unset for unset values with no default. If the `-c` option is used on a pre-existing Commit or Edge server spec, additional recommended fields might be shown if they are not already configured. You can include other configurables that affect the behavior of the server. To learn more, see Configurables.

## Options

`-c edge-server | commit-server` | Allow the user to set, change or display configuration values used to set up the multi-server environment on an edge or commit server by using the DistributedConfig: field. Configuration fields are initially populated with: The configured values, if set. Default values, if unset `unset` for unset values that with no default value. After exiting from the form, any configuration commands in the DistributedConfig: field will be run on the current server for the scope of the serverID. The commands only apply to the serverID server, and so the server# prefix is not allowed in these commands. The only supported services are `edge-server` and `commit-server`. The service dictates which configuration values are used to populate the form the first time that the server command is run.
`-d serverID` | Delete the named server specification.
`-g` | Generate a new serverID as part of the form.
`-i` | Read a server specification from standard input. You can combine this option with the `-c` option to generate and run configuration variables used to set up an edge or commit server. When used with `-c`, only the fields explicitly set in standard input from the `DistributedConfig:` field will be configured.
`-l` | Deprecated because of the functionality of the DistributedConfig: field.
`-o` | Write the named server specification to standard output.
`g-opts` | See Global options.

## Usage notes

Can File Arguments Use Revision Specifier? | Can File Arguments Use Revision Range? | Minimal Access Level Required
--- | --- | ---
N/A | N/A | Only standard users with the super access level can add or modify server specs because only super users have access to `p4 server serverID` and the `-i`, `-g`, and `-d` options. Standard users can view server specs by using the `-o serverID` option. Operator users and service users have no access to the `p4 server` command.

## Related commands

Get or set the unique ID associated with a P4 Server. | `p4 serverid`
To list all known servers | `p4 servers`

Your search for returned results