Today we're excited to ship and launch Travis CI Enterprise, a self-hosted version of Travis CI that runs inside your datacenter.
Over the past months and years, we've been approached many a times by companies wanting to run Travis CI on their own premises, utilizing their internal GitHub Enterprise installations.
Travis CI Enterprise supports GitHub.com and GitHub Enterprise, allowing you to bring all the features that make Travis CI great into your own datacenter, making it easy to scale out build infrastructure based on your company's needs.
Runs on your infrastructure
With Travis CI Enterprise, you can fully utilize internal and existing infrastructure. Whether you're using OpenStack, VMware, or bare metal servers.
It's optimized to run on EC2 as well, and it's fully based on the new Docker build stack that we shipped earlier this week.
Running on EC2 allows you to scale out capacity and save costs based on demand throughout the day or week.
Customize the build environment to your needs
With Travis CI Enterprise, you can customize the build environment to reflect your specific needs. Whatever services and language versions you need to have installed by default, thanks to Docker, you can provide your own images, speeding up builds significantly, removing the need for any customization and slowdown during the build.
Just like hosted Travis CI, our Enterprise version integrates with your existing GitHub instance. You can easily use it with LDAP directories, as login, authentication and authorization are strictly tied to the users you already have set up in GitHub Enterprise.
The licensing is done per seats, where every license includes 20 users. Pricing starts at $6,000 per license, which includes 20 users and 5 concurrent builds. There's a premium option with unlimited builds for $8,500.
Does Travis CI Enterprise support Stash, Gitorious, or any other version control system?
Travis CI Enterprise focuses on a tight integration with GitHub and GitHub Enterprise. While we don't have immediate plans to support other platforms, do get in touch if you have specific needs, as that gives us clues for our product roadmap.
How is it installed?
We ship you a set of two images, one containing the base installation, and another one that includes the job worker, which you can install on the machines you want to dedicate to running builds.
Can I provide my own Docker image?
Yes, you can. Travis CI Enterprise fully supports bringing your own set of images so you can tailor the build environment to suit your needs.
Can I dedicate more resources to my Docker containers?
By default, the containers run with 2 cores and 4 GB of memory. While that can't be customized just yet, it's something we're looking into adding in the future.
Want to try out Travis CI Enterprise on your infrastructure or on EC2? Get in touch, and we'll get you set up!.
Stability and reliability in your builds is the one thing we aimed to give since
Travis CI came about. But we haven't always been able to live up to this
expectation. Network issues, insufficient build capacity (for open source
projects) which in turn lead to long wait times for your build to start,
constrained CPU and memory resources in the builds environment, lack of caching
for open source projects. As most our current Linux stack runs on a private
cloud, we've also had issues adding capacity, as we had to go through the
process of ordering and waiting for more capacity.
Today we're happy to announce our new build infrastructure, which addresses some
of these issues. It's available for private and open source repositories as of
What benefits does this new infrastructure have?
Builds start in seconds
Rather than wait for builds to start for a long time, your builds now start in
less than 10 seconds. Assuming that capacity is available (which is now a lot
easier for us to scale), you'll see your builds going from being scheduled to
starting in only a few seconds.
We've been helping projects move over to this new stack, and we've seen much
better build times for most of them. The mileage may still vary based on how
heavy your builds are on I/O, but most projects should see an improvement. We'd
love to hear from your if you don't or if you see slower build times.
More available resources in a build container
The build containers in our legacy build infrastructure have had 1.5 cores (with
burst capacity) and 3GB of memory. The CPU resources are now guaranteed, which
means less impact by noisy neighbors on the same host machine. Build times
throughout the day should be much more consistent on the new container stack.
The new containers have 2 dedicated cores available and 4 GB of memory.
Better network capacity, availability and throughput
Our new stack is running on EC2, which means much faster network access to most
services, especially those hosted on EC2 as well. Access to S3 is now also a ton
faster than on our legacy stack.
Caching available for open source projects
The best news for open source projects is that our build caching is now
available for them too. That means faster build speeds by caching dependencies.
Make sure to read the docs before trying it out.
For Ruby projects, it's as simple as adding cache: bundler to your
Easier to scale
This might not be a direct benefit to our users and customers, but it is one for
us. We can now respond to demand much quicker and increase our build capacity in
mere minutes. That allows us to ensure that open source projects are less likely
to hit capacity peaks and wait in line for too long until they run.
How can I use it?
Using our new container-based stack only requires one additional line in your
What are the restrictions?
Using sudo isn't possible (right now)
Our new container stack uses Docker under the hood. This has a lot of benefits
like fast boot times and better utilization of available machine resources. But
it also comes with restrictions imposed by security.
At this point, it's not possible to use any command requiring sudo in your
If you require sudo, for instance to install Ubuntu packages, a workaround is to
use precompiled binaries, uploading them to S3 and downloading them as part of
your build, installing them into a non-root directory.
Databases don't run off a memory disk
On our legacy and legacy legacy stack, both MySQL and PostgreSQL ran off a
memory disk to greatly increase transaction and query speed. This can impact
projects depending on their use of transaction, fixtures and general database
usage, but the impact generally shouldn't be negative.
Tell me about this new stack?
Over the past year, we've been working on Travis CI
Enterprise, our on-premises solution for
GitHub Enterprise customers. Part of working on this stack required us to think
about how to best run on custom infrastructure like internal OpenStack, VMware
and other virtualization setups, and even on bare metal hardware.
Our legacy stack runs on a proprietary, managed cloud with APIs not available in
our customers' datacenters. Both for packaging our entire stack for
installation, but also for running builds in isolated environments, we started
looking at Docker as an alternative about a year ago.
Our new stack can run on pretty much anything we or our customers would like it
too. That allows for custom Travis CI Enterprise installations on EC2, Digital
Ocean, Linode, Rackspace, or fully in-house infrastructure.
We've verified a few options upfront, but EC2 turned out to have the better
performance and more reliable network.
Our new stack for hosted private and open source projects is running on EC2
inside of Docker containers. We've seen great performance both in the network
and with compute resources, and the direct access to S3 makes build caching a
I have more questions...
Can I provide my own Docker containers?
The build environments we're currently using on our Docker-based setup provide
the same services, programming languages and tools offered by our legacy stack.
We've been keeping them on par as much as possible.
The lack of sudo does make it hard to install custom libraries and services,
running them on privileged ports, or simply using apt. The question for
providing your own images is a natural one.
We're not there yet in allowing you to bring your own, but it's something we
have in mind for the future.
Can I build Docker containers as part of my build?
Same as the above. It's not currently possible, mostly for security reasons, but
is something we want to address in the future.
Can I run Docker inside Docker?
Running Docker containers as part of your build currently isn't possible because
of questions related to security due to the underlying container technology. We
have things planned to address this in the future.
This is only the beginning of offering better, faster and more reliable builds
on Travis CI. We have a lot more things planned to improve stability, but we're
excited to ship this today.