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

P4 Server Administration Documentation | 2025.2

# How server types handle requests

Server types differ in how they respond to user commands.

Type | Global update commands | Read-only commands | Work-in-progress commands | Note | To learn more, see ...
--- | --- | --- | --- | --- | ---
Standard | Local | Local | Local | A standard server can be a standalone server or the central server that has downstream replica servers. |
Commit | Local | Local | Local | A commit server The innermost P4 Server server in a topology with one or more edge servers. is required as the central server when the topology includes edge servers, but a commit server can also be a standalone server. The commit server stores canonical archives and permanent metadata. It is not required to contain all the workspace, label, or shelf information that is held locally by edge servers. Commit servers can operate with only edge servers connecting to them, and the users only connecting to edge servers. However a commit server can also operate in a hybrid mode, where both users and edge servers connect directly to the commit server. Commit servers also support connections from other replica types, proxies, and brokers. | Commit-edge
Edge | Forward | Local | Local | Edge servers A server that is part of a commit-edge environment that can independently support work in progress for locally-bound clients, thereby reducing the load on the commit server. can provide excellent performance in many scenarios. For example, performance might improve when the users are geographically near the edge server but distant from the commit server. By default, edge servers handle their workspaces, labels, and file locks (non `+l` files) locally. Syncing, opening files, running merges, and viewing file history are all handled by the edge server. However, the commit server does become involved when a submit command is issued to an edge server. | Commit-edge
Replica | Reject | Local | Reject | A readonly replica A P4 Server that automatically maintains a full or partial copy of the central server's metadata and that might contain related file content. The replica copies by using 'p4 pull' or 'p4 journalcopy'. A replica can be used as a backup server for disaster recovery. server processes readonly commands from users and contains all metadata that the upstream central server contains (unless it is filtered). | Read-only replica
Standby | Reject | Local | Reject | A standby server supports the same set of functionality as the read-only replica but in addition: Uses p4 journalcopy and `p4 pull -L` for metadata replication. Allows the use of the p4 failover command for failover against mandatory servers. | Standby server
Forwarding Replica | Forward | Local | Forward | A forwarding replica A P4 server that processes reporting (read) commands but forwards update (write) commands to the central server. Forwarding replicas can reduce the workload of the central server and be used as a backup server for disaster recovery. offers a blend of the functionality of the P4 Proxy with the improved performance of a replica. A forwarding replica handles commands that only require a read from the database but forwards commands that require a database write to the upstream server. | Forwarding replica
Forwarding standby | Forward | Local | Forward | A forwarding standby provides the same functionality as a forwarding replica, but in addition: Uses p4 journalcopy and p4 pull -L for metadata replication. Allows the use of the p4 failover command for failover against mandatory servers. | Standby and forwarding-standby
Build | p4 client | Local | p4 sync | A build server offloads the workload of the automated build processes onto a separate machine. In addition to supporting read-only commands, build servers host their own local copies of certain metadata concerning workspaces and the syncing of files. Server functionality has advanced since build servers were implemented and we now recommend using edge servers (available since 2013.2). Edge servers provide additional capabilities which further reduce the load on the central server. This improves performance and adds the flexibility of being able to run write commands as part of the build or development process. To learn more, see Commit-edge. | Build server

Server type corresponds to the `Services` field in the server specification. To learn more, see Form fields under p4 server in the P4 CLI Reference.

User requests fall into three categories, depending on the command and command options:

Global update | Read-only | Work-in-progress
--- | --- | ---
p4 branch p4 change p4 configure set p4 client p4 counter p4 depot p4 group p4 job p4 label p4 protect p4 renameclient p4 renameuser p4 server p4 stream p4 triggers p4 typemap p4 user | p4 branches p4 changes p4 configure show p4 client -o p4 clients p4 counters p4 depots p4 dirs p4 filelog p4 files p4 fstat p4 fixes p4 groups p4 interchanges p4 jobs p4 labels p4 opened p4 servers p4 streams p4 sizes p4 user -o p4 users p4 where p4 workspaces | p4 add p4 edit p4 delete p4 diff p4 integrate p4 reconcile p4 resolve p4 revert p4 shelve p4 submit p4 sync p4 unshelve

Your search for returned results