160 results found
-
Allow managed backups to other regions
All backups currently go to the USA. This is slow and expensive for those of us in other parts of the world (as well as introducing data sovereignity issues). It would be great if other regions were supported as well, or even better, if backups could be configured to use S3 buckets that we could supply.
4 votes -
Add `cx toolbelt` to homebrew
Then we don't have to look up how to install it.
4 votes -
Make it easier to download backups
With one of my stacks, I currently have to download 80 tar chunks and reassemble them. This isn't viable as a long term soluton. Please just provide a link that will let me download the whole (large) file.
1 voteManaged Backups can be restored to databases via the Cloud 66 UI:
https://help.cloud66.com/docs/databases/database-backups#restoring-database-backups
-
Give users the ability to choose which database to backup
Currently, I can have managed backups for all my databases. In my case this is Postgres and Redis.
I don't really need/want backups for Redis. They actually create high Disk I/O issues on my redis server. But right now it's all or nothing, so I have to have Redis backed up.
I would appreciate the ability to choose which DB to backup.
8 votes -
Sync time between servers in Stack
When provisioning a stack, make sure the timezones/time configurations
are same on all servers (web app, database, etc).3 votesAccount owner can set the global settings for timezone for applications in the account overview.
-
Allow different timezone for servers and cloud66 UI
The timezone setting in the cloud66 account setup controls timezones for servers and the web UI. I want my servers to run on UTC and I'd like to be able to see times as CST in the web UI. It would be nice to have two different timezone settings for each of these use cases.
1 voteserver timezone can be adjusted in the account settings.
-
adding new servers via API
It would be nice to have an api that creates a new process server, so that people would love to create a server from the app. Say for example, if in case of sysytem like building seperate servers for each accounts, then it would be useful
1 vote -
Allow access to some historical deployment logs
If you have a bad deployment, you don't want to leave your stack in a bad state. However, doing another deployment means you can no longer access the deployment logs for the bad deploy.
Having the deployment logs from the last N (7 days, 5 deployments, whatever, I understand you wouldn't want to keep them forever) deployments would make the logs available for diagnosis once a stack is in a good state again.
4 votesHistorical logs are now available via the timeline:
https://help.cloud66.com/docs/deployment/deployment-history#
-
Create SSH Tunnel via CX
Sometimes for debugging I want to access a service as if it's local. This is especially useful for databases. Right now, I can use CX to open an SSH connection, but setting up a tunnel must be done manually, and it takes some work finding the right credentials.
I could see this being used in a couple different ways:
a) cx ssh -s [stack] -e [environment] --tunnel [remotehost]:[remoteport]:[localhost]:[localport] server_nameb) cx databases tunnel -s [stack] server_name
Option (a) is generic, while option (b) meets the exact need I have. It could infer ports from its knowledge…
14 votes -
Allow a custom server hostname on creation
When spinning up a new cloud server, it would be great to be able to specify the name of the server, instead of using an automatically-generated animal name. For example, I might create a new custom server called "Background Worker 1". Its hostname would be "background-worker-1", and its domain would be "background-worker-1.stack-name.c66.me".
14 votessupport for naming a server via the manifest has been added. The key "unique_name" can be used in the manifest.
https://help.cloud66.com/docs/manifest/building-a-manifest-file#server-definitions
-
hangs on preparing server
hey there - my deployment is hanging on the preparing server step - what should I do?
1 votePlease contact support for deployment issues. A support ticket can be created from the top right of the dashboard.
-
Allow multiple SSL certificates per stack
You can currently only have one SSL certificate per stack. Since it's possible to route domains to containers it would be great to have one SSL certificate per container. This would make cheap people (like me) very happy because wildcard certificates are sooo expensive :)
1 voteWe have added support for wildcard certificates:
-
Toolbelt: ssh to a running container
You can currently only ssh to the host that runs the docker containers, or you can ssh to an image of your container, but not to an already running container.
It's very useful to ssh to a container in order to troubleshoot issues. Allowing cx to do that (by providing a container id) can save the trouble of first ssh'ing to the host, checking the running container is (docker ps) and executing an interactive shell.4 votes -
Allow redeployment of a single docker service.
When you make a change to one docker image, getting that deployed is very time consuming. It rebuilds all the docker images on that stack and deploys each one - even though only one service has changed. So either interrogate the git sha to see if the service needs rebuilding/redeploying, or allow a single service to be redeployed via command line or/and UI.
7 votesThis is already possible through toolbelt: http://help.cloud66.com/toolbelt/toolbelt-stack-management#redeploy :) Please let us know if you have any questions!
-
Improve stack list loading time
Right now, the ajax request to load our stacks list (https://app.cloud66.com/stacks_list) is REALLY slow. We see load times around 4-5 seconds on avg for that page. We have roughly 30 stacks. It's extremely annoying to have to wait every time we navigate to the main stacks list since that's the main screen we navigate back to.
1 vote -
Docker stacks - redeploy only if monitored branch has been pushed
Similarly to suggestion - https://cloud66.uservoice.com/forums/176741-general/suggestions/4270169-only-redeploy-based-on-a-webhook-if-the-relevant-b but for docker stacks.
The services.yml file configures a git_branch, but currently it's only used as the source of where to take the files to deploy. Every commit to the repo will trigger stack deployment, which means that every commit to a feature branch (many times a day..) triggers a deploy.
3 votes -
Kubernetes support
OpenShift -> https://blog.openshift.com/openshift-v3-deep-dive-docker-kubernetes/
And Meteor Galaxy -> http://info.meteor.com/blog/meteor-and-a-galaxy-of-containers-with-kubernetes
Are both choosing Kubernetes as foundation for their next generation PaaS.
I was wondering does cloud66 has any plans to integrate with Kubernetes ?4 votesSupport for containerization has been added.
-
Provide a 'Preview' button
I would like a button (or menu item) that launches a browser already pointing to my running server. It is a bit of a nuisance to copy/paste the long - unique - URL into a new browser tab/window just to preview my work.
Admittedly, I am coming from Nitrous (have been a long-time fan and one of the original beta-testers) and this is a standard feature I expect.
1 voteA link to each server can be found in the server page of the Cloud 66 UI. A direct link to the site can also be found near the application name on the applications dashboard.
-
Specify git-ref in redeployment hook
We invoke the redeployment hook from our build server when the corresponding branch passes all tests. However, if during the build someone pushes more changes to the branch then untested changes can be deployed as C66 deploys the HEAD of the branch.
I'd like to be able to specify the git-ref to deploy as a parameter so that I can know the tested version is what will be released.
As an added benefit this would allow us to deploy any branch, with the configured one being the default if nothing is specified.
6 votes -
Add labels to firewall rules
Given our service oriented architecture, we have lots of different firewall rules opened up for different machines on different stacks. It's impossible right now to know what rules are for what other stacks and why they're there. Also our local ssh firewall rules sometimes get out of date if our local IP changes, but we're wary of removing rules because we don't know exactly why they're there.
I'd love to be able to label these rules so we have context into why they're open. (eg: "Office", or "AuthService" etc)
4 votes
- Don't see your idea?