This topic assumes you have read the Guidelines for setting up multi-server services

Consider using the commit-edge architecture because it can provide excellent performance in many scenarios. For example, performance might improve when the users are geographically closer to the edge server than the commit server.

The configuration of an edge serverClosed A server that is part of a commit-edge environment that is able to independently support work in progress for locally-bound clients, thereby reducing the load on the commit server. is defined on a commit serverClosed The innermost Helix Core Server Server in a multi-server topology that implements the protocols required by Edge Servers.. 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".