Roadmap

[gianarb]

This issue acts like an easy roadmap where we can collect desires, features requests, idea.

I like to have actionable issues and clear stakeholders so my proposal is to use a format like the following:

- feature title (proposer, other stackholders): short description
like:
- Add delete capability to the ctl (@gianarb, @jacobsmith928 ): reuse the kubectl command similar to what we did for get

When an idea turns to something we want we can turn it into an issue, link it into this issue and work at it.

---

• Delete, update, apply commands (@gianarb): from the kubectl as we added the get command feat: add crud and other basic commands #48
• Design an e2e test suite( @gianarb): usually ctl is a good place to start an e2e test suite since it pretty at the end 🥳 of the stack
• Update dependencies (@gianarb): renovate bot opened a good amount of issues, I think it is a good time to spend some time fighting with go mod go mod tidy
• Group commands in help (@gianarb): right now all the commands are one after the other. kubectl groups them, and it looks a lot nicer e40fd5a
• helping move release workflow over to a github app secret instead of a PAT (@scotwells)
• have a story about how we want to do markdown documentation (@scotwells )

[jacobsmith928]

@gianarb have you considered using the Discussions area for this?
https://github.com/orgs/datum-cloud/discussions/categories/feature-requests

[gianarb]

We did, Scot enabled issues for this repo but for me whatever works for you works for me. I just feel like I need a place where we can collect quick notes and ideas that are not yet articulated or complex enough to be issues or feature requests on their own. We can move this as discussion in the other repo and disable issues. As you prefer Il 11 gennaio 2026 17:22:37 CET, Jacob Smith ***@***.***> ha scritto:

…

jacobsmith928 left a comment (datum-cloud/datumctl#47) @gianarb have you considered using the Discussions area for this? https://github.com/orgs/datum-cloud/discussions/categories/feature-requests -- Reply to this email directly or view it on GitHub: #47 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[jacobsmith928]

Carry on @gianarb !

[scotwells]

@gianarb here's a few other items that come to mind:

• Support multi-environment authentication - The auth login command accepts a --hostname flag that can be used to influence which environment to authenticate against (e.g. datumctl auth login --hostname auth.staging.env.datum.net). This is useful for development purposes, but will also have value in the future if users decide to host their own version of Datum Cloud. Today, the CLI will overwrite existing credentials if a user with the same email address is already authenticated against a different environment. Ideally I'd be able to use datumctl auth switch to switch between users instead of having to re-authenticate.
• Authenticate without a browser - The authentication process relies on the user having a browser on the same host as datumctl to handle the OAuth code exchange challenge. Ideally we would also support users being able to receive a code in a browser on another computer that they can feed into the CLI's authentication process so it can complete the code challenge. Google and other providers have this capability.
• Configure CLI defaults - We should allow users to set default parameters that are used on the CLI when a command is invoked so they do not always need to specify --project or --organization. Users should be able to easily see what contexts they have access to and be able to switch between them.
• Test resource access - We should integrate the kubectl auth can-i command so users can test their access to resources on Datum Cloud.

[scotwells]

Couple others that come to mind:

• Provide upgrade instructions: We have installation instructions, do we need to provide a similar document that's focused on upgrading?
• Publish documentation to datum.net: We should publish our datumctl documentation to datum.net ideally in an automated fashion so that this repo can be the source of truth.
• Show datumctl guides after authenticating: After a user authenticates with datumctl auth login, they're redirected to our documentation site home page. This isn't super helpful because they still need to go find the documentation they're looking for. It would be better if we landed them on a splash page that's focused on "welcome to datumctl" with quick links they can use to get started.

[scotwells]

• Embed version info - Compile the version information into the binary so users can easily confirm what version they're running.