This topic assumes you have read Deployment architecture. We recommend you consider commit-edge because it can provide excellent performance in many scenarios.

The configuration of an edge serverClosed A replica server that is part of an edge/commit system that is able to process most read/write commands, including 'p4 integrate', and also deliver versioned files (depot files). is defined on a commit serverClosed The innermost Helix Core Server in a multi-server topology that includes edge servers. The commit server processes submitted files (changelists), global workspaces, and promoted shelves.. A checkpoint of the commit server is then used to create the edge server. Regarding that checkpoint see [-R service | -P server-id] -jd [-z] file

  • The p4 unsubmit and p4 resubmit commands can be issued to a commit server, but not to an edge server.

  • Commit-edge architecture builds upon Helix Server replication technology. Before attempting to deploy a commit-edge configuration, read Replication, including the section on Connecting services, which includes information on Managing SSL key pairs.

  • An edge server can be used instead of a build server. If the only users of an edge server are build processes, disaster recovery is possible without backing up the local edge server-specific workspace and related information. See Migrating from existing installations.


Some Helix Core Server commands behave differently when you have edge servers. See the Support Knowledgebase article, "Edge Servers".