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

A handy feature would be a BASIC AUTH option on a web end point/load balancer. on nginx you would do something

server {
        listen 80;
        server_name your_domain.com;

        location / {
            auth_basic "Restricted Access";
            auth_basic_user_file /etc/nginx/.htpasswd;
        }
}

Rather than have to deploy nginx into a cycle env and proxy all traffic via it just to put basic auth, it would be nice to have a "not intended for production use" option on an environments load balancer/firewall to do basic auth.

Two choices would be available: 1) Apply basic auth to the entire env 2) Apply to selected containers

and finally a simple gui to add basic auth users..

Please consider adding a compress option to log drain form in environment settings panel.

Reference documentation here.

From my initial observation, compressed request bodies are unusual in HTTP traffic, but not impossible. When sending the request with compressed body, client must trust that the server is able to decompress the request body data. Server can decompress request body data based on Content-Encoding header sent by client, i.e.: Content-Encoding: gzip

Cycle agent pushes logs in a format, that is highly compressible (NDJSON). Client or, in Cycle case, Agent side compression may reduce network traffic for logs by 10x and more.

Example curl for compressed request body:

# compress json data
gzip -9 -c body.json > body.gz
# send compressed data
curl -v --location 'http://my.endpoint.example.com' --header 'Content-Type: text/plain' --header 'Content-Encoding: gzip' --data-binary @body.gz

If destination server does not support request decompression, apache httpd can do it with the following directives:

LoadModule deflate_module modules/mod_deflate.so
SetInputFilter DEFLATE
ProxyPass "/" "http://upstream/"

Please add auth option for external log drain requests. That way we can protect our log ingest endpoint by allowing only authorized agents.

Reference documentation here.

Proposed solution:

• Add an optional write-only auth field in the logs config form.
• If auth field not empty, add Authorization header with the value from auth field on requests to external log drain endpoint.

Example:

auth field contains value Basic YWRtaW46cGFzc3dvcmQ=, results in a header Authorization: Basic YWRtaW46cGFzc3dvcmQ=

This also allows for other types of auth, like Bearer and Api-Key tokens.

Please add environment_identifier to exported logs so we can have a name instead of hash for switching between environment log views in our Grafana log dashboard.

Reference documentation here.

Proposed fields:

• If NDJSON - Headers is selected, X-Cycle-Environment-Identifier header is added.
• If NDJSON - Raw is selected, environment_identifier field is added.

The value is the same as identifier field in environment settings page.

Example NDJSON raw request body:

{
  "time": "2025-08-07T11:11:11.12345678Z",
  "source": "stdout",
  "message": "some log message",
  "instance_id": "instanceid",
  "environment_id": "environmentid",
  "environment_identifier": "my-environment",    <---- please add this
  "container_id": "containerid",
  "container_identifier": "my-container",
  "container_deployment": "my-deployment",
  "server_id": "serverid"
}

*the json in example above was formatted for convenience. NDJSON body actually contains one json object per line, each representing a log message.

Hey All! I love the automatic lockdown on SFTP as it seems like bots are crazier than ever these days; however, I'm having trouble seeing when my server is in lockdown and when it's out without reconciling with the activity event log. Would it be possible to make this change to the portal, where it is easy to tell the state of SFTP (Locked Down vs Not Locked Down)?

I have found that 50% of the time I connect to the container SSH endpoint it is to find an IP address on one of the interfaces. Most of my containers don't have the ip command so I have to install that, too. It would be great if we could see all interface IP assignments directly in the portal.

Our containers are generally built with minimal dependencies so as to minimize the attack surface. This means they don't normally have curl/wget/netcat. There is a funky shell trick, but it's .... ugly. Would it be possible to add a cycle-native HTTP/HTTPS health check?

Ugly Script

exec 3<>/dev/tcp/localhost/5000 && \
  echo -e "GET /_ah HTTP/1.1\r\nHost: localhost\r\nConnection: close\r\n" >&3 && \
  cat <&3 | grep 200

One of the deployment patterns we have been using from K8S is to generate unique configmaps per deployment of a service so that we can version variables with the code (but outside of the image). We have been able to achieve that using the existing Stack spec (nice work on this, btw), but it would be great if we could clean them up when the deployments get removed in the pipeline step.

Microsoft recommends the XFS filesystem for SQL Server on Linux data volumes. Would it be possible to allow us to specify which filesystem should be used when provisioning volumes?

From https://learn.microsoft.com/en-us/sql/linux/sql-server-linux-performance-best-practices?view=sql-server-ver16:

SQL Server supports both ext4 and XFS filesystems to host the database, transaction logs, and additional files such as checkpoint files for in-memory OLTP in SQL Server. Microsoft recommends using XFS filesystem for hosting the SQL Server data and transaction log files.

The current server view depicts base storage usage and trending over time; however finding out what's consuming that space currently isn't possible. As you reach your threshold, there are no granular views to figure out what might be consuming the space.

Since base storage expansion is possible but decreasing it is not, we're thinking that a way to determine if we need to expand it is necessary to make decisions on whether we have a machine with runaways storage logs (consuming base storage) or too large of images for a given machine.

When pipelines make use of parameters it is sometime cumbersome to fill in all the info to re-run a failed pipeline.

This is especially true when debugging pipelines that were triggered by automatic processes that make use of parameters to identify builds.

For server storage, it would be nice to see the potentially allocated volumes (thin provisioned) that exists for container volumes which reside on that server. If we have an instance A that has thin-provisioned a 30GB disk, and another instance B with 100GB of thin-provisioned space, then we could potentially have overprovisiond according to what physically exists on disk. This is especially crucial if for some reason the workload is placed on a server with other running volumes that we are unaware are taking up chunks of the disk that are unussed.

While thin-provisioning is the way to go, it presents problems if not visible when the disk begins to quickly be consumed. This can cause other resources to starve or the entire machine to go unresponsive.

Hey all. We've got a slack channel that has feeds from our main providers in it where any service degradation or outages get sent, like in the attached image.

Given Cycle's a pretty load bearing part of our infrastructure, I'd appreciate a slack feed like the ones we have for other several other providers, as this channel is my first port of call when something weird is happening.

In DNS -> Zones and Cluster Drain JSON data ( as well as other places) it would be super helpful to have cluster ID information. Since environments can be replicated, it is important for the API to carry the cluster ID / name to differentiate environments.

Hey y'all, we recently had a volume growth due to an unexpected internal error on our web app. I know you're working on monitoring. Could you consider adding an alert for volume growth over time if it exceeds some amount set by the user? Thanks!

Hi!

I deployed a container with a high availability deployment strategy on two instances, assigning a tag that I previously associated with the servers. To manage the containers, I created Scoped Variables using Container Identifiers as the binding. However, the containers share the same identifier. How can I use one of the variables with different values depending on the container instance?

Thx