Deprecating Older Solano CLI Versions

As part of a backend upgrade, we will be deprecating versions of the Solano Gem older than ‘1.30’.

We believe we have identified and emailed anyone still using older versions. If you are using a version older than ‘1.30’, please upgrade ASAP.

If you any questions, contact us at

Leave a comment

Announcing Custom Worker Volumes

At Solano Labs, we like to get more done faster. Solano CI was designed from the beginning to run tests faster by running them in parallel on multiple workers, and many of the features we’ve rolled out over the years were implemented with the goal of getting customers’ build results back to them as quickly as possible.

Another benefit of Solano CI is the customization of the build environment. We want our workers to emulate customers’ development/production environments, not the other way around. Our base workers have a great many software packages, libraries, daemons, and other executables pre-installed. This allows for quicker builds, as activating a package and/or specifying its version in a solano.yml configuration file is faster then installing it in every build.

With the goal of further improving build speeds and allowing customers to accurately match the build environment with that of their development/production systems, we are introducing Custom Worker Volumes. Instead of running builds on our default worker volume, this feature allows running builds on a worker volume of your choosing.

For now, Ubuntu 14LTS and 16LTS worker volumes can be selected, but with Solano BX powering this feature, completely custom worker volumes will soon be selectable on a per-repo or even per-branch or per-profile basis:


We had planned on waiting until the workflow/UI for customizing worker volumes was more polished before announcing this feature, but the release of Chrome version 59 adjusted our timeline. Chrome broke compatibility with our default worker volume (Ubuntu 12LTS) some time ago, and while we had been maintaining compatibility ourselves, the requirements for versions 59 make this no longer possible.

We have example configurations for packages that require Ubuntu 14 or higher customer worker volumes for:

Let us know what you think!

Leave a comment

Migrating from Snap CI to Solano CI

As many in community are already aware, Snap CI will be retired in August of 2017. The offered migration is to GoCD, an on-premise CI/CD solution – as this product may not fit the needs to current SnapCI customers we felt it was appropriate for us offer a comparison to Solano CI so that customers migrating are choosing the most appropriate and easiest product to migrate onto.

Solano CI is a cloud-based CI/CD SaaS that allows customers to unlock incredible performance from their existing test suite. Solano CI customers have seen 10x improvements in testing time using our unlimited parallelism, advanced caching, and extremely customizable build process. Not only that, but Solano CI is extremely easy to get running and simple to customize to fit your exact build workflow.

Comparison of Solano CI to Snap CI

Here is a quick rundown of the main differences between Solano CI and Snap CI:

Solano CI to Snap CI Comparison


We’re confident that Solano CI can get existing Snap CI customers running with their desired CI workflow in no time at all. Sign up for a free account and try us out – check out our documentation or contact us at if you’d like to have a conversation about the migration process.

Leave a comment

Outbound Web Hook Closures

Solano CI supports sending outbound web hooks that contain various information about the status of a Solano CI session. These web hooks are great for collecting data on your Solano CI builds, but many of our users wanted the flexibility to send custom-formatted JSON blobs directly to third party services. Introducing:  Web Hook Closures

Now, Solano CI supports adding a Javascript function that processes the JSON data before sending out web hooks. This will allow users to transform the JSON into a format that can be automatically recognized by any third party service that accepts incoming web hooks. Here is a simple example closure for posting session time stamps to New Relic insights (gist); simply replace the Insert Key with your API key.

Please let us know if you run into any issues, or have an exciting closure to share!

For additional information, consult the Solano CI Documentation or contact us directly at


Leave a comment

Announcing Solano CI and Google Auth Integration

We’re happy to announce our integration with Google Auth. New users can now immediately sign-up using their Google credentials, and existing users can link their Solano CI and Google accounts to allow for quicker logins.

Screen Shot 2017-02-21 at 10.45.30 PM



Existing users can visit this link to manage their Google Authentication settings. Please contact us with your feedback!

Leave a comment

Shiny New Session Lifecycle Display

You might’ve already noticed, but your Solano CI report page may look a little different than you’re used to. We’re excited to release our newly redesigned Lifecycle display, giving you more insight into your build’s timing and progress.

Solano CI Lifecycle Header

This new lifecycle header splits your build into 4 logical sections:

  1. Startup – This phase includes the time it takes from receiving notification that you would like to start a build, to the time that Solano CI workers are assigned and your code changes have been pulled.
  2. Prepare – This phase includes any setup needed in order to successfully run your tests. This includes running setup and worker hooks, as well as initializing services you may have configured (postgres, mysql, elasticsearch, etc…)
  3. Run – This is where we run your tests. Nothing more complicated going on here.
  4. Finish – After your tests are completed, we run post build hooks, collect and upload logs, and complete any other teardown requested.

We’ve also made all of the timing data used to create this new heading available to users through our outgoing webhooks API.

Let us know what you think. This lifecycle update is a part of our ongoing focus on giving Solano CI users more visibility into every step of their CI build. Stay tuned for more releases in this vein.

Leave a comment

Managing AWS Credentials in the Cloud

Anyone who uses AWS and CI/CD long enough has invariably been told to store their AWS credentials in Environment Variables in order to use the AWS CLI to manage deployments or pull resources from S3. This is extremely unsafe for a variety of reasons.

AWS has been recommending cloud-platform providers to utilize the AssumeRole API to provide another layer of security and traceability to external AWS Credential access. As a proud APN DevOps Competency Partner, we’re excited to be the first cloud CI/CD provider to announce our adoption of AWS AssumeRole as the recommended & most secure way to use AWS Account Credentials with your Solano CI builds!


Using AssumeRole w/ Solano CI

Follow the instructions here on setting up a cross-account AssumeRole policy in AWS. Make sure to follow the section that mentions “Allows IAM users from a 3rd party AWS account to access this account”.

You will be prompted for the External ID and AWS Account ID for the external account, you can find this information in your organization’s settings page.

Continue through the instructions, and copy the ARN for the new policy into the organization settings page and click “Save AWS AssumeRole ARN”. We will run a test to make sure the role has been set up correctly, and you will be presented with the following success message:


You can now use the AWS Code Deploy / Solano CI integration without the requirement of having to include Environment Variables with your build! You will also have access to the following temporary AssumeRole Environment Variables that will allow you to authenticate AWS requests using the new role:


Use these exactly as you would’ve used hard-coded environment variables, without the guilt of hard-coding your secure never-expiring credentials!

As always, please reach out to us via if you have any additional questions!


1 Comment

Announcing Solano CI Tutorial & New GitHub Integration

Solano Labs is excited to announce the release of our brand-new GitHub Integration!

Using the newly built GitHub Integration, we are able to provide a catered onboarding tutorial that shows you how CI/CD works within Solano CI – all using free open-source codebases. The tutorial walks users through:

  1. Forking one of our open source example repositories:
  2. Installing the Github Integration and granting access to your new fork
  3. Editing and automatically committing a solano.yml from Solano CI
  4. Watching the tests run and pass!

In addition to enabling this more robust onboarding flow, GitHub Integrations aim to give users more fine-grained control over the permissions granted to third-party applications. You can now give Solano CI access to your code on a repo-by-repo basis, eliminating the need for confusing bot accounts. The integration also gives the ability for Solano CI to have write access to your solano.yml, which will be used for smart  in-app editing of your Solano Configuration.

If you know of an Open Source project that has CI needs, and you’d like to see it featured as a part of our tutorial flow, please reach out to us at

This onboarding tutorial is available to all newly created trial accounts. Please give it a try and let us know what you think!

We’ll be giving the option for current GitHub OAuth Integration organizations to migration to the new GitHub Integration in the next few months – if you’d like to explore migrating sooner, please reach out to us at

1 Comment

Introducing Solano Labs 30/30: 30% Faster Builds or 30% Lower Bill

Solano Labs is proud to announce our most ambitious campaign to date. Our 30/30 promotion offers you 30% faster builds or a 30% lower CI bill. No catch. It truly is that simple.

Our technology is the most scalable in the industry and we are happy to issue an open invitation for anyone to try it by providing an extraordinary benefit in the form of faster builds or lower cost. We are bringing the classic soda blind taste test to the enterprise software world, so try Solano CI today and experience our patented auto-parallelization and newly redesigned onboarding flow and decide for yourself. It is easier than ever to set-up a Solano CI account and get your build turnaround time down to #coffeetime–  the time it gets to get a cup of coffee.

Here’s how you can get in on the 30/30 action:
Spending over $1000 on CI per month?

  • Sign up for this special offer on this page.
  • Connect your repo and provide your current CI configuration.
  • Give us a few days to show you how much time or money you can save.
  • Pick Faster builds or Lower Cost.
  • Use the time or money you saved to throw a party for your team. Cheers!

Spending less? We got you covered too. Save 30% on your CI bill with Solano CI, connect a repo to get started.

Now relax and brew some coffee with the confidence that by the time your cup is ready your tests will be done and your team ready to continue working on core mission, not wrangling with test environments. Welcome to #coffeetime.

It’s a bold move, but we are confident in our industry-leading speed and customer support. For more information on Solano Labs 30/30 visit, visit us at AWS re:Invent (Booth #2320), or join the conversation on Twitter at #coffeetime.

1 Comment

Solano Platform Status Update- November 2016

First and foremost, we want to apologize for delays that some customers have recently experienced with Solano CI. We are in the process of addressing a chain of related issues that emerged over the last week. We’d like to explain what these issues are and how we’ve been addressing them.

The first issue emerged on Tuesday, Nov. 1, when Solano CI began to experience capacity constraints that limited the number of sessions we could support in our SaaS production environment. To the best of our understanding, this capacity issue was due to an unusually high demand for the AWS instance type that Solano CI commonly uses for its production workloads. For some time, Solano was unable to allocate new, healthy AWS instances with our preferred type and region.

In an attempt to mitigate this issue, the Solano team migrated capacity to different instance types that we determined as suitable backups when our preferred types are unavailable. These instance types required enough additional storage that using many of them bumped against an account-level volume limit size imposed by AWS; this killed some instances in use. Because of decreased supply (fewer instances available) and increased demand (restarting killed sessions), build queues backed up. We manually managed them during peak hours to limit slowness and worked with AWS to increase that storage limit, but it took multiple days to complete the process. With the higher limit, we are again able to spin up sufficient capacity for our full peak load.

Coupled with that, the high number of restarts affected other parts of the Solano system. Last week’s unusual load stressed Solano’s infrastructure, including the database, in unprecedented ways. Although most issues are resolved, we are working on one component that seems to be causing some customers’ builds to restart unexpectedly. This is still affecting queue throughput, and is now the critical priority for our engineering team.

Again, we apologize for the effect this has had. We understand how valuable fast builds are to your productivity, and are working to correct the problem as quickly as possible. We will continue to update this blog as more information is available. In the meantime, please don’t hesitate to contact if you have any questions or concerns.


The Solano Support Team

Leave a comment