Feature Requests

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

Allow the enforcement of 2FA on member invites and accounts. Ensuring that downline devOps and admins have 2FA enforced is mission critical for compliance.

To complete the notification process for internal/external teams on upgrades to environments, it would be nice to be able to use the pipeline variables. Use cases include posting the previous revision/build ID and the upgraded one or to indicate the cluster/environment modified.

With stacks/pipelines, you could adding near duplicate pipelines by having conditional logic. Consider this scenario

• You define a DEBUG_LEVEL scoped variables variable as GLOBALLY scoped.
• You define a specific workload to override DEBUG level conditionally IF set.
• You could then conditionally set the debug-level variable on a pipeline, if you happen to need the variable overridden for a given deployment you could set debug level to 'high' and deploy, and override the variable for that deployment.

Currently there's limitations as you need to stop an instance for ENV variables to take effect, and redeploying isnt viable as currently, that always requires the environment variable to be set.

Implementation suggestions (should you permit these :))

• Mark build variables for stacks as 'optional', as well as in pipelines. If the variable is set, you'll send the value to the pipeline/stack, and then the stack can optionally define the variable and even a fallback if necessary.

One of the most useful features on AWS Lambda is the ability to set a CRONTab schedule for automated triggering of the function. That would be a really handy update to the current Function configuration!

Hey all!

I've got a heterogenous cluster where some nodes are CPU heavy and others memory heavy. I'd like to deploy particular workloads to particular nodes if there's space, but I'd much prefer that deploys didn't fail if there's space on another node, just not the one I want. One way I can imagine this working is assign a list of tags [cpu-pool, pool] and have the scheduler try to match as many tags as possible, failing only if it can't match a single one. So an ANY rule in addition to your current ALL implementation, I suppose?

As it stands I'm a bit nervous to configure my preferred split because breaking deploys is a bigger downside than optimising node usage is an upside.

It would be nice to have an overview of the currently attached scoped variables that apply to this instance. This helps with understanding which variables are / are not attached in the event there's conflicting (or wrongly configured) scoped variables that do not have this container in their scope. This helps even more when changing tags and they no longer apply to containers.

I would like to submit a request for a feature. VMWare has a feature called DPM (distributed power management), I think a similar feature in Cycle could be very useful. Power up and down hosts then rebalance workloads as needed based on workload resource consumption. Thanks!

Hey all, bit of context: I have a generic pipeline that deploys all my services. This works well, but given only one run of a pipeline can be performed at a time, it leads to sequential runs when they could be parallelised (to give a concrete example: a deploy to service A's staging environment will block a deploy to service B's UAT environment).

I'd like to opt in to some control in the pipeline run and provide a lock token of some kind (which would in my case probably be a string that combines the target environment and target cluster, say, to guarantee only one run can touch service A's staging environment at a time, for example).