When choosing only selected database tables to PUSH or PULL from staging to live website it is VERY difficult to both read or find the tables because of you choice of layout. I'm numbering things so replies can reference each point.

PROBLEMS

1. Tables are listed in four columns
2. Tables are inside a quite small iframe that forces us to scroll around 6 pages in length... it's like only being allowed to look through a peephole at large document.
3. Table names are truncated with an ellipsis (...) if they don't fit in the width of the column and for me that's about half of my tables. This means that I have to hover my mouse over every one of these cells to figure out what the actual full table name is, a very slow process.
4. Since tables are in columns it makes it very difficult to find things alphabetically, especially since many of the table names are even fully visible because of truncation (see problem 3).

SOLUTIONS

1. Use a single full-with column to list tables so names can easily be found alphabetically and without truncation.
2. Database tables should not be listed within an iframe if at all possible. If you insist on using an iframe then make it like 2000px tall or dynamic height if possible so we can see more than a few table names at once... very hard to use.

Please, consider adapting the Dashboard to allow the adding of Ed25519 keys for SSH sessions.

RSA, the cryptographic method currently in place for SSH sessions, is mathematically breakable, which is why long keys are necessary to keep security; nevertheless, there is always the possibility they could be cracked. Also, for long term protection, RSA keys should now, supposedly, contain at least 15360 bits; of course, this is unrealistic in a real environment, as it decreases performance and increases strain on the communication channels.

I pledge for the usage of Ed25519, considering a mere 256 bit key is enough to guarantee long term protection, simplifying drastically the identities used for logging into servers and increasing security all at the same time.

OpenSSH, the SSH software ran on most Linux servers, just like my Cloudways Digital Ocean droplet, has supported Ed25519 cryptography since v6.5, released in January 2014, meaning most servers should support it out of the box. My specific server runs OpenSSH v7.4, for example, many releases ahead of the one with the Ed25519 implementation.

Even though it might sound a little tricky, this suggestion should not be too complicated to implement: the software to handle these cryptographic method is already in place in most, if not all servers, so the only thing necessary to get this online is a change in the front-facing console, or Dashboard, clients like me use to configure their servers. It would, however, significantly improve security for SSH connections and make them airtight for the future, as well as tranquilising the few of us, such as myself, who dread of seeing their RSA keys cracked by someone malicious.

Once again, please consider taking action on this.

Apologies, I am sure most or all of these have been suggested and I am suggesting a few at once here.

• File manager

• Ability to rename accounts. I am a developer and have 5 accounts and more soon that I am working on for different clients. In the drop down it shows their name, I should be able to rename it so I see the name of the client, not the name they signed up with which sometimes is not someone I know and am not sure which websites it is and need to click around to find the correct account.

• Login timeout. If I don't use the Cloudways admin page for as little as an hour or two I get logged out and need to log back in. I think the timeout should be at least 12 if not 24 hours. I waste a lot of time each day waiting to log back in (click on a link, the single application page loads, then it realizes I am timeout, redirects me to the login screen, need to log in, land back on the main page with the servers, need to click into where I wanted to be...)

• Link should be openable in another tab. Nothing in the CW admin that is a link is an actual link. It is all controlled with JS, so I can't right click and open in another tab.

Currently the created date only shows on the "Applications" page, which paginates apps in groups of 10. We've go over 150 apps, so when we need to find the created date we have to trawl through pages to find the correct app.

So it would be super helpful to have the "Created Date" for an application within the details of a single app. As for where, maybe above/below the "Applications Management" title on the left hand side. Or below that menu? Or within one of the pages - e.g. Access Details.

Should be super simple to add in wherever! Just somewhere within the single app :)

Thanks!!!

The ability to add a team member to an account is great, but it would be even better if we could request access to another account.

That way, I wouldn't have to send my clients instructions on how to add me as a team member. Instead, I could just request access to their account, then they can approve or deny the request by clicking an email link, much in the same way the server migration between accounts works.

GoDaddy has this in place with their 'delegated access' feature, I'd love to see Cloudways implement the same. It's a big time saver.