March 6th, 2025 - Chris Aubuchon, Head of Customer Success

3 Neat Tricks and New Patterns Used in Cycle - from Cycle's Customer Success Team

In the last few months I've had the privilege to implement and witness new and exciting Cycle platform workflows emerging. Some of these come from the evolution of our own internal work, while others I've learned from our users.

Reflecting on this, I thought it would be beneficial to the community to share!

In this article, I'll walk through a handful of the neatest patterns we've seen in action. So I hope you'll join me for a no fluff, real, and practical look at how to get more out of Cycle.

Ultra Dynamic Pipelines

Almost all of Cycle users take advantage of pipelines and rainbow deployments. Some of our users have moved to implementing ultra dynamic pipelines, or, setting up a pipeline that can be used to deploy any stack in their hub to any environment.

create a tunnel page 3

Here is a basic example that shows how flexible a pipeline can be using a combination of resource path identifiers and pipeline variables.

From the image we can see that the flexibility of this pipeline is derived from the following:

  • stack-resource-identifier: A resource path identifier that is passed in to identify the stack being used.
  • version: A pipeline variable that sets the version on the deployment.
  • environment: A pipeline variable that sets the environment resource path identifier.
  • current-tag, previous-tag: A way to pass tagging information used for deployments.

Most users implement this type of dynamic pipeline using trigger keys to plug into the CI stack. The nice thing about tying into, say, Github Actions, is that most of these variables are static to the repo they're being called from, in fact for the demonstration deployment shown above, the version is the only non-static variable and most Cycle users will consume the commit sha for this field, making it automatically assigned. Therefore, a lot of the perceived complexity is statically defined within the repository making the actual management of those variables trivial.

Cycle Official Github Action

With so many of our users consuming Github and Github Actions, our Head of Engineering Alexander Mattoni wrote a custom Pipeline Runner Github Action that's available on the Github marketplace.

This custom action:

  • ✅ Triggers a Cycle pipeline using the provided Pipeline ID
  • ✅ Passes optional variables and advanced settings
  • ✅ Tracks each step as it progresses
  • ✅ Logs when each step starts and completes
  • ✅ Fails fast if a step fails

Path Matching for SEO

During Q2 and Q3 of last year we wanted to invest in our website SEO while expanding our existing application catalog. The approach we took was two tiered.

  1. We took all properties that were under subdomains and planned to move them to a single domain to maximize SEO.
  2. We added a learn center and community application in order to draw a wider audience and provide value to the end user.

The consolidation of our applications under a single domain meant we would need to route incoming traffic to 4 different web properties based on the request path matching. We took advantage of Cycles native V1 load balancer's advanced routing and path matching to accomplish this.

The four properties would live at the following paths within the domain:

  1. /docs
  2. /community
  3. /learn
  4. And the base website which would be the route defined in the router at the bottom of the list.

To make sure incoming requests go to the right place we added 4 new routers to the environment these containers were living in.

Now with routers the order of the definition matters immensely as the first router matched (always evaluated from top to bottom) will take the request.

Each application was set to expect incoming requests on the path we set for the special routing through the load balancer router via path match.

The path match works with a regular expression. For example, in the docs router we used: ^/docs(/|$|\.).

This regular expression is used for matching URL patterns that begin with /docs and may continue in specific ways. Below is a detailed breakdown of each component:

^ - Start of String Anchor

Ensures that the match begins at the very start of the string.

/docs - Literal Match

Matches the exact string /docs.

(/|$|\.) - Group Matching ((...))

This group allows for three possible matches after /docs:

/ - Forward Slash

Indicates that more path segments may follow, e.g., /docs/example.

$ - End of String Anchor

Ensures /docs can be a standalone match.

\. - Literal Period (.)

Matches file extensions like /docs.pdf.

We followed the same pattern for the other properties and then added a catch all router at the bottom of the routers list for requests that would match the website.

By implementing this new architecture, we were able to consolidate what would have been 4 different applications (and counting as we are adding our 3 official API docs apps here as well), without needing to use subdomains which are penalized in SEO.

User Uploaded Certificates

A new feature that's been rising in popularity is the ability for users to upload their own certificates in conjunction with the platform DNS tooling. This has become especially popular for users that want to run Cloudflare load balancers as the main entry point to their applications but still want to terminate those connections at the Cycle load balancer.

Following this pattern, users can take advantage of Cloudflare's smart geographic routing, reducing latency for their end users while still being able to take advantage of a lot of the magic that Cycle has to offer between the load balancer and the container via Linked Records.

Most users will design this using non-hosted zones on Cycle. In a non-hosted zone, the platform nameservers aren't authoritative so a majority of the DNS records will still live at your provider. However, the user does still have the ability to use the user uploaded certificates along with the linked records. This pattern teaches the load balancer what container incoming traffic for a given domain needs to go, but it does not affect DNS queries for the given domain.

The normal toolset for Cycle DNS takes advantage of Let's Encrypt (through Cycle) to create certs. However, following the user uploaded certificate pattern, it is up to the user to upload a new certificate when the old certificate needs to be rotated out. So, to accompany this feature we've built out a way to deprecate the existing certificate if the user wishes to do so. There are then two ways to rotate the certificate:

  1. Upload a new cert and if the existing certificate is 10 days or less from expiration, the platform will look for the new cert and use it.
  2. Upload the new cert and mark the existing cert deprecated, causing the platform to immediately start looking for a replacement.

What's Next?

The only thing that remains constant is change, and while in software that can be met with mixed reactions, in my experience that's been a very positive thing. I look forward to being continuously impressed with the creativity and ambition of Cycle users and can't wait to see what they come up with next!

💡 Interested in trying the Cycle platform? Create your account today! Want to drop in and have a chat with the Cycle team? We'd love to have you join our public Cycle Slack community!