- or
No existing idea results
- ~ No ideas found ~
184 results found
-
More groups in Rolling Deployment
Increasing the number of groups in a rolling deployment would be more feasible for certain deployments. It would also allow us to run better than half capacity.
1 vote -
Have a way to copy jobs when cloning
Whenever we clone a cloud machine, we should have a way to copy the jobs as well. Or export the job and reimport it. It'd save us alot of time when we are trying to replicate the production's site.
2 votes -
Support Kubernetes Autoscaling with KEDA
We have a lot of sidekiq queues that would benefit from this.
For example, we have 6 pods running for sidekiq which are only used between 00:00-06:00 and we could scale up other parts of our app after these jobs have completed but right now I would have to manually do this.
6 votes -
Update the API docs
The API is very handy when you need to automate stuff but the documentation is not up to date. I would rather not have to bother the support with questions regarding missing things in the docs.
1 vote -
Ability to set up firewall rules through manifest file
Add an option to automate firewall rules installation through manifest.yml file
e.g.
staging:
firewall_rules:
from: 127.0.0.1/16
to: 123.123.123.123
protocol: tcp
port: 221 vote -
Read only users for Slave databases
As per the Ruby on Rails guide for a multi db setup;
the username for the writers and replicas should be different, and the replica user's permissions should be set to only read and not write.
1 vote -
Ubuntu 20.04
Allow deployment to Ubuntu 20.04
1 vote -
Partner with UpCloud
I want to deploy to UpCloud and not have to create registered servers.
1 vote -
Add headers to deployment health checks
With deployment health checks, it would be useful to be able to specify HTTP headers such as authorization or "Host". It may be beneficial to accept arbitrary
curl
options.3 votes -
Deploy Elixir/Phoenix as easily as Ruby/Rails
It would be great if deploying an Elixir/Phoenix app were as easy on C66 as deploying a classic Ruby/Rails app.
3 votes -
cx tunnel: add option to open a ssh tunnel into an existing container
In many stacks, I use dockerized databases such as Redis, Solr or even Postgresql.
With "cx run -s mystack --container web-123 -I 'bash'" the cx toolchain allows me to directly get a bash in an already running container, e.g. to perform checks or development changes.
It would be much more convenient however, if I had the possibility to open as ssh tunnel into these containers so I can access their (mapped) port locally and use all the great database tools out there. :) Just like with "cx tunnel".
3 votes -
Add the option to importing specific backup from one stack to another in the UI
The import database feature can be used to test staging environment against production data. Having a way to specify the exact backup ID to import (rather than only having the very last one available) in the UI - with a dropdown or text field entry for the backup ID will be useful to cover more testing scenarios.
1 vote -
Better visibility into build
Deploying a new Maestro stack builds a "master" server, but C66 does not have good enough status about what's going on as it builds. The last update received is "Kubernetes: Service deployments complete", but it's been spinning doing something for almost 40 minutes since, without having any idea what's going on.
3 votes -
Always show the current stack without scrolling
With a lot of stacks, it is impossible to know what stack I'm currently looking at without repeatedly scrolling up to the header and the back down to what I was looking at. With multiple tabs open in order to try to copy settings, for instance, it makes it incredibly difficult to know what I'm looking at.
The name of the stack being viewed should always be visible in the top fixed header.
1 vote -
Add the possibility to increase shared memory size
The option to specify shm_size in service.yml or anywhere else.
3 votes -
clean removal of all added AWS services when deleting a project
Hey,
I am using c66 now for quite some time and projects, and recently stumbled on this: when deleting a project, it removes the main EC2 instance on AWS, but leaves behind:
- volumes
- load balancers
- security groups
- key pairs
Not sure about the RDS instance, for that short-lived project, I opted to just have the db run on the one EC2 instance as well..
I would actually expect, that every additional service added for a project is cleaned up on AWS when deleting the project. At least a little warning would be nice, or a checkbox asking, if you want to remove all the extras as well.
Maybe that option was given and I overlooked it, its already quite some weeks ago, that I removed said project.
Thanks and all the best,
LudwigHey,
I am using c66 now for quite some time and projects, and recently stumbled on this: when deleting a project, it removes the main EC2 instance on AWS, but leaves behind:
- volumes
- load balancers
- security groups
- key pairs
Not sure about the RDS instance, for that short-lived project, I opted to just have the db run on the one EC2 instance as well..
I would actually expect, that every additional service added for a project is cleaned up on AWS when deleting the project. At least a little warning would be nice, or a checkbox asking, if you want…
1 vote -
Enable secondary backup location for managed backup
In addition to the primary, default location where backups are stored (in same region as the server), allow us to configure an optional second location so that in case of certain types of disasters or outages, the backup is effectively 'offsite', so it can still be accessed for the purpose of eg bare bones recovery.
3 votes -
Provide 'Publish' Service cx Command
In the UI, there’s the ability to
Deploy with Options...
for an Application and you can select to onlyPublish
a service.It would be great to have a cx command to do the same thing instead of a full redeploy. One of the use cases we have is we're updating environment variables so we just need to Publish. It’s much faster and it wouldn't use the extra BuildGrid time.
This works with CSv1 but does not work with CSv2.
1 vote -
Add commit hash to application card in dashboard
It would be great if the commit hash was also included in the application card within the dashboard view. Currently, it only shows the branch that is deployed to, but it doesn't show which commit was last deployed. Why does this matter? I have two "application" cards in different environments (staging and production). I can't easily see whether staging and production are running on the same commit, or if production is behind. I know I can hover over the branch name to see the commit hash, but I have to do that twice to compare the hashes. Additionally, on some screens the hovered text goes off screen and I'm not able to see the full hash.
It would be great if the commit hash was also included in the application card within the dashboard view. Currently, it only shows the branch that is deployed to, but it doesn't show which commit was last deployed. Why does this matter? I have two "application" cards in different environments (staging and production). I can't easily see whether staging and production are running on the same commit, or if production is behind. I know I can hover over the branch name to see the commit hash, but I have to do that twice to compare the hashes. Additionally, on some…
1 vote -
For Jobs, have extra info so it'll help us debug easier
I think what will be useful if we can get what's schedule when the cron job is being run (eg "every 5 minutes", "daily at 1 AM" etc.) on the Jobs overview table.
When trying to figure out what a performance issues, this data is valuable if it's in the Job's overview table
Thanks
1 vote
- Don't see your idea?