Overview

CircleCI is a modern continuous integration and continuous delivery (CI/CD) platform. The CircleCI Enterprise solution is installable inside your private cloud or data center and is free to try for a limited time. CircleCI automates build, test, and deployment of software.

Basic Features

After a software repository in GitHub or GitHub Enterprise is added as a project to the CircleCI Enterprise application, every new commit triggers a build and notification of success or failure through webhooks with integrations for Slack, HipChat, Campfire, Flowdock, or IRC notifications. Code coverage results are available from the details page for any project for which a reporting library is added.

CircleCI may also be configured to deploy code to various environments, including the following:

AWS CodeDeploy

AWS EC2 Container Service (ECS)

AWS S3

Google Container Engine (GKE)

Heroku

Other cloud service deployments can be easily scripted using SSH or by installing the API client of the service with your job configuration.

Build Environments

By default, CircleCI Enterprise comes with a general-purpose image based on Ubuntu 14.04 (Trusty). It is possible to customize this image if necessary.

Architecture

CircleCI Enterprise consists of two primary components: Services and Builders. Services run on a single instance that is comprised of the core application, storage, and networking functionality. Any number of Builder instances execute your jobs and communicate back to the Services. Both components must access your instance of GitHub or GitHub Enterprise on the network as illustrated in the following architecture diagram.

Services

The machine on which the Service instance runs must not be restarted and may be backed up using built-in VM snapshotting. Note: It is possible to configure external data storage with Postgres and Mongo for high availability and then use standard tooling for database backups. DNS resolution must point to the IP address of the machine on which the Services are installed. The following table describes the ports used for traffic on the Service instance:

Source

Ports

Use

End Users

80, 443

HTTP/HTTPS Traffic

Administrators

22

SSH

Administrators

8800

Admin Console

Builder Boxes

all traffic / all ports

Internal Communication

GitHub (Enterprise or .com)

80, 443

Incoming Webhooks

Builders

The Builder instances run without storing state, enabling you to increase or decrease containers as needed. To ensure that there are enough Builder machines running to handle all of the builds, track the queued builds and increase the Builder instance machines as needed to balance the load.

Each machine on which the Builders are installed reserves two CPUs and 4GB of memory for coordinating builds. The remaining processors and memory create the containers. Larger machines are able to run more containers and are limited by the number of available cores after two are reserved for coordination. The following table describes the ports used on the Builder instances:

GitHub

CircleCI Enterprise uses GitHub or GitHub Enterprise credentials for
authentication which, in turn, may use LDAP, SAML, or SSH for access. That is, CircleCI will inherit the authentication supported by your central SSO infrastructure. The following table describes the ports used on machines running GitHub to communicate with the Services and Builder instances.

Source

Ports

Use

Services

22

Git Access

Services

80, 443

API Access

Builder

22

Git Access

Builder

80, 443

API Access

Help make this document better

This guide, as well as the rest of our docs, are open-source and available on GitHub. We welcome your contributions.