Latest Threads

Issue

Currently our nodes have a couple of IPs attached (not floating) to each, then when spinning up a new environment and assigning a load balancer (ha or not) it will fail as it does not check if that node has enough available IPs.

Idea

Load Balancer should check before starting instances if there are enough free IPs on that servers pool.

Issue:

We have fixed IPs per server, and should a LoadBalancer be shuffled around, the IP will also change. This would mean the hardcoded IPs in the VPN configuration now are invalid.

Idea:

Ability to add a hostname and let the cycle LBs figure out how to route traffic to the VPN server using the Hosted Zones records.

Considering suggestion in my prev request is to open multiple tabs in browser, this is hard to look for both, when both tabs reserving space for left part of dashboard. It would be nice to have button "hide" or "shrink" the configuration pane

I'd like to have an ability to use ssh from my own laptop, sending bash commands. But currently there is only possible to connect to the machine and execute withing attached terminal

I'd like to see logs in descending order, there is no order selection for logs in containers.

Also - scroller is not responsive, you can drug browser scroll all the way down, then it's stuck, and you have to scroll by mouse wheel. At least that how it works in firefox

Will be good to filter scoped variables by:

• scope
• container
• name (identifier)
• etc

For instance I want to see both scoped variables that are for same container to see the difference between stage and prod, at same time

I'm putting the same user credentials in for all the image sources that pull repos from our org's GitHub account. Can cycle add shared credentials that can be referenced when creating new image sources?

Hi Cycle team,

I noticed two new endpoints in the environment monitoring config for metrics and events. For custom events, it looks like the only option available right now is providing a destination URL.

We use Atlassian Opsgenie, which uses a global destination url and requires sending an API key to be included in the request header for authorization.
Example:

curl -X POST https://api.opsgenie.com/v2/alerts \
  -H "Authorization: GenieKey API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "message": "CPU usage critical",
    "tags": ["cpu", "production"]
  }'

It would be helpful to have an option to include an API key (or custom headers) as part of the configuration, so it can be sent along with the request.

This enhancement would enable direct integration with services like Opsgenie and other systems that require header-based authentication, improving flexibility and reducing the need for intermediary solutions.

Hi Cycle team 👋

We’d love to see support for encryption at rest — either at the server disk level or at the individual volume level.

For teams deploying workloads in third-party virtualized environments, this is becoming a pretty standard requirement.

⸻

Why We’re Asking

When running in a virtual provider environment, we don’t physically control the underlying hardware. Even though TLS handles encryption in transit, we still need guarantees around data stored on disk.

For many companies (especially those dealing with customer or regulated data), encryption at rest isn’t optional — it’s table stakes for production.

This impacts things like: • Enterprise security reviews • SOC 2 / ISO 27001 compliance • GDPR / HIPAA workloads • Internal security policies • Risk mitigation around snapshots / host access

Without it, some workloads just can’t move onto the platform.

⸻

What Would Help

Any of the following would be great:

1️⃣ Host-Level Disk Encryption • All server disks encrypted by default • Transparent to containers • Configurable per environment if needed

2️⃣ Volume-Level Encryption • Encryption on specific persistent volumes • Visible status in the UI and API • Clear documentation on how it’s implemented

3️⃣ Key Management Options (Stretch Goal) • Bring Your Own Key (BYOK) support • Key rotation visibility

While the current default of RAID1 configuration provides a reliable foundation for data integrity, it would be beneficial to have more flexibility in how Cycle handles storage.

In scenarios where we are utilizing distributed storage solutions like Garage, redundancy is already managed at the application level. In these cases, the ability to prioritize maximum storage capacity over local hardware redundancy would be highly advantageous. Furthermore, providing users with granular control over which specific storage devices are assigned to a container or VM would significantly improve resource optimization and environment customization.

With the new dashboard for environments, it would be super handy to add a dedicated circle for core services (like LBs, VPN, discovery, etc) and also something to signal that a core service has updates available on the cards as well as the dropdown list.

This would make it super easy to spot any updates/issues that are not related the the 100's of containers circle. Also maybe on the dropdown list a smaller range preview of the new Uptime bar.

Not a big deal, but one thing I often find myself annoyed by is when I restart an instance, having to open the instance to watch the instances and wait until they pass the health check and are ready. It would be nice if, for services with defined checks, the Instances column right now that currently shows a count of instances and a ring that indicates how many are running and how many are not could also somehow indicate how many are ready vs just running. Maybe with color-coding? Right now the ring just shows green for running without regard for readiness - maybe add an intermediate different color like blue for running but hasn't passed the health check yet and only go green once the instance is actually ready?

Hey all,

This one's a bit in the weeds but here's the context:

• I use stack definitions for each of our services, and deploy those using a generic pipeline that uses a bunch of variables to determine what environment we're deploying to, what stack definition to use and a couple other things.
• Each service has a couple of one-off jobs that need to run once, on deploy, and then basically never again. This is hard to model in the current Cycle approach because unless I explicitly stop each container, by name, after it's run once, each of these containers will get a platform health check every 10 minutes and a restart.
• This is the only thing I can't dynamically control in the pipeline and as such the only thing that's preventing a single pipeline for all deploys.

What I would like:

• A way to tag or otherwise mark a container in a stack definition such that I can act on all containers with that tag in a pipeline. In my specific case, imagine a tag called migration (the canonical example of this sort of workload is a database migration, hence the tag) where in a pipeline step I can just say "now stop all containers tagged migration. That'd very neatly solve my problem.

In my specific case I could model all of these as function containers and I could also use a 'now stop all function containers' type grouping but I'd imagine that'd be much less broadly useful to others.

One feature I'd really love is the ability to execute a restart as a "rolling" restart. Right now, manual restarts (hitting the button, applying a config change, etc) stop all instances at once producing app downtime. And without a defined health check policy there's probably no way around that. But when a health check policy IS defined, I would love to be able to set the default restart method to a rolling restart where each subsequent instance restart does not begin until the previous instance reaches healthy status. That functionality would be incredibly valuable in such a wide variety of situations...

Hi everyone,

Over the holidays, a new MongoDB vulnerability was published that involves the ability to dump uninitialized server memory over the network without authentication. The attack is rather easy to exploit, and simply requires an out of date version of Mongo + using zlib compression.

We wanted to bring this to our community's attention, as many of you are running Mongo on Cycle. And, as many of you know, we use Mongo internally to power the platform. To be clear, Cycle itself was not affected by this vulnerability. Nevertheless, we've upgraded to a patched version to be on the safe side.

If you're at risk, especially if you're running Mongo publically on the internet, then you should also upgrade right away to one of these patched versions:

• 8.2.3
• 8.0.17
• 7.0.28
• 6.0.27
• 5.0.32
• 4.4.30

If you're running Mongo on Cycle with public internet DISABLED, then you're most likely fine, but we still urge you to upgrade just to be safe.

Read more about the CVE here, and feel free to reach out to our team if you have any questions/concerns we can help with.

Hey all, today we are unable to log into the Cycle Portal, because of an error on the login page. I've attached a screenshot showing 401 HTTP errors and a (maybe resulting)JS error.

Hey team, I'd love to see readiness checks added to stack! While the LBs do a good job of assessing latency for packets; they truly can't tell if a a container is in trouble and 'just needs a moment to process/recover'. A readiness check is a method to tell the deployment manager (don't reboot me, but I need a second, stop talking to me). The readiness check is separate from the health check (which is really a liveness check) - as it purely indicates if the instance can serve traffic at the moment.

We all need a moment to compose ourselves sometimes, so do our instances.. Give them a fighting chance!

For LB containers/instances, please add in the source IP address (seen as CF-CONNECTING-IP) so that we can source the original IP of inbound connections in LB logs. The current logs limit us to seeing a proxy IP address (which is always CloudFlare on certain IPs) and when watching LB logs, it would be nice to see both the proxy IP address as well as the source IP.

See https://developers.cloudflare.com/fundamentals/reference/http-headers/ for more information on CloudFlare headers.

Please add a /health or /status endpoint to the Cycle.io API that returns the operational status of the service. This would enable proper health checking and monitoring for applications that integrate with Cycle.io.

Proposed endpoint: GET https://api.<customer_id>.cycle.io/health

Expected response:

  {
    "status": "ok",
    "timestamp": "2025-10-17T17:00:00Z"
  }

Use case: This endpoint would allow our services to implement readiness probes that verify Cycle.io API availability before accepting traffic, improving reliability and enabling circuit breaker patterns for graceful degradation when the API is unavailable.

HTTP status codes:

• 200 - Service operational
• 503 - Service unavailable (optional, for maintenance windows)

Would be nice to have a feature to verify that RAID configurations were set up properly during deployment