Codefresh Installation Options
How to run Codefresh in the Enterprise
Codefresh offers 3 installation options that can cater to any size of organization:
- Full cloud version that runs 100% in the cloud and is fully managed by Codefresh.
- On-premise version where Codefresh runs inside the customer datacenter/cloud.
- Hybrid version where the UI runs in the Codefresh cloud, but builds are running on customer premises.
On-premise and Hybrid versions are available to Enterprise customers that are looking for a “behind-the-firewall” solution.
The Cloud version is the easiest way to start using Codefresh as it is fully managed and runs 100% on the cloud. All maintenance and updates are executed by the Codefresh DevOps team.
You can also create a free account on the SAAS version right away. The account is forever free with some limitations on number of builds.
The cloud version runs on multiple clouds:
Codefresh Cloud is also compliant with SOC2 - Type2 showing our commitment to security and availability.
The Cloud version has multi-account support with most git providers (GitLab, GitHub, Bitbucket) as well as Azure and Google.
For organizations that don’t want their source code to leave their premises, or have other security constraints, Codefresh offers the hybrid installation.
The User Interface still runs on Codefresh infrastructure, while the actual builds happen in the location of the customer (Codefresh builders run on a Kubernetes cluster).
The hybrid installation strikes the perfect balance between security, flexibility and ease of use. Codefresh still does the heavy lifting for maintaining most of the platform parts. The sensitive data (such as source code and internal services) never leave the premises of the customers.
With the hybrid installation mode, Codefresh can easily connect to internal secure services that have no public presence. The UI part is still compliant with Soc2.
Here are the security implications of the hybrid solution:
|Company Asset||Flow/Storage of data||Comments|
|Source code||Stays behind the firewall|
|Binary artifacts||Stay behind the firewall|
|Build logs||Also sent to Codefresh Web application|
|Pipeline volumes||Stay behind the firewall|
|Pipeline variables||Defined in Codefresh Web application|
|Deployment docker images||Stay behind the firewall||Stored on your Docker registry|
|Development docker images||Stay behind the firewall||Stored on your Docker registry|
|Testing docker images||Stay behind the firewall||Stored on your Docker registry|
|Inline pipeline definition||Defined in Codefresh Web application|
|Pipelines as YAML file||Stay behind the firewall|
|Test results||Stay behind the firewall|
|HTML Test reports||Shown on Web application||Stored in your S3 or Google bucket or Azure storage|
|Production database data||Stays behind the firewall|
|Test database data||Stays behind the firewall|
|Other services (e.g. Queue, ESB)||Stay behind the firewall|
|Kubernetes deployment specs||Stay behind the firewall|
|Helm charts||Stay behind the firewall|
|Other deployment resources/script (e.g. terraform)||Stay behind the firewall|
|Shared configuration variables||Defined in Codefresh Web application|
|Deployment secrets (from git/Puppet/Vault etc)||Stay behind the firewall|
|Audit logs||Managed via Codefresh Web application|
|SSO/Idp Configuration||Managed via Codefresh Web application|
|User emails||Managed via Codefresh Web application|
|Access control rules||Managed via Codefresh Web application|
For customers that wish to have full control over everything, Codefresh also offers an on-premise option. In this case everything (UI and builds) are running on an environment (Kubernetes cluster) fully managed by the customer.
While Codefresh can still help with maintenance of the on-premise platform, we would recommend trying the Hybrid solution first as it offers the most flexibility while maintaining high security.
|Managed by||Codefresh||Codefresh and Customer||Customer|
|UI runs on||public cloud||public cloud||private cluster|
|Builds run on||public cloud||private cluster||private cluster|
|Access to secure/private services||no||yes||yes|
|Customer maintenance effort||none||some||full|
|Best for||most companies||companies with security constraints||Large scale installations|
|Available to||all customers||enterprise plans||enterprise plans|
High level Architecture
The most important components are the following:
The Codefresh VPC: This is where all internal Codefresh services are running (analyzed in the next section). Codefresh is using internally Mongo and PostgreSQL for storing information such as users and authentication.
The Pipeline execution environment. This is where all pipelines run. The Codefresh engine component is responsible for taking pipeline definitions and running them in managed Kubernetes clusters by automatically launching the Docker containers that each pipeline needs for its steps.
External actors. Codefresh is offering a public API that is consumed both by the Web User interface as well as the Codefresh CLI. The API is also available for any custom integration with external tools or services.
If we zoom into the Codefresh Services platform we will see the following:
pipeline-manager manages all CRUD operations regarding pipelines
cfsign signs server tls certificates for docker daemons and generates client tls certificates for hybrid pipelines
cf-api is the central backend component. It functions as an API gateway for other services and is also responsible for authentication/authorization.
context-manager manages all possible authentication/configuration that are used by Codefresh system and by Codefresh engine
runtime-environment-manager is responsible for managing the different environments where pipelines can run. The Codefresh SAAS installation has runtime environment that are fully managed by the Codefresh team. In hybrid installations, customers can add their own runtime environments using private Kubernetes clusters
hermes controls trigger management in Codefresh
nomios enables triggers from Dockerhub (when a new image/tag is pushed)
cronus enables defining cron like triggers for pipelines
cf-broadcaster stores build logs from pipelines (the replacement for Firebase in the previous installer). The only component that the UI and CLI have access to through a web socket in order to stream logs.
cluster-providers provides an interface to define clusters contexts for connecting Kubernetes clusters in Codefresh
helm-repo-manager is responsible for the Helm repository admin API and ChartMuseum proxy for managing Helm charts it Codefresh
k8s-monitor is an agent that gets installed on each Kubernetes cluster to provide information for the Kubernetes dashboards
charts-manager models the Helm chart view in Codefresh.
kube-integration provides an interface to retrieve all required information from a Kubernetes cluster, can be run either as a http server, or npm module
tasker-kubernetes provides cache storage for Kubernetes dashboards in Codefresh