Skip to content

Atlas

Share your idea. In order to help prioritize, please include the following information

  1. A brief description of what you are looking to do
  2. How you think this will help
  3. Why this matters to you

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback

8 results found

  1. Granular Permissions

    Right now Mongo Atlas allows you to assign two types of roles to all the users: Organization and Project, and for each set it gives you some predefined roles.

    The problem with this is you can't have any kind of granular control of what permission is assigned to each user. (e.g. to allow a user to create a trigger through Mongo Stitch it needs the Project Owner role).

    This is a major setback as I'm giving my coworkers more access than needed.

    A good solution would be to have something like the database access control in this part so we…

    456 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    started  ·  57 comments  ·  IAM  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  2. Option to restore one or more db from snap to cluster. Right now, it involves manual dump and restore

    Currently we can only restore full cluster from backup like snap using GUI interface. If we want to restore one or more specific db, it needs manual dump and restore from backup. if we have an option to restore specific db to cluster through GUI interface, it will be very useful.

    164 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    37 comments  ·  Backup  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Hi all – We are currently developing collection and database-level restores. We expect this feature to be released in CY2025, but will update here once it is launched.

  3. API Key Expiration date

    We have a security reqirement that secrets must expire after 2 years.

    Therefore it would be awesome if MongoDB Atlas API Keys would support an expiration date.

    Somethig similar exists for the IP Whitelisting. Here we have the option to remove IP Whitelist entries after er certain time period. But for API Keys it would be better to have an expiration date and keep the API Key in the list even if its expired.

    In addition it would be good to have a daily notification once the expiration date is ahead less than 30 day.

    19 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    started  ·  8 comments  ·  IAM  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  4. API Improvements - OpenAPI and more auth options

    The API should be documented with OpenAPI to allow better tooling.

    Ideally using the above OpenAPI spec you could auto generate a SDK or API client for popular languages.

    Lastly, the API should accept authentication options other than digest. There is very poor support for digest authentication by popular HTTP clients. I don't like trying to implement security protocols myself, as there is often some quirk I have not fully understood that ends up leaving me less secure than I hoped.

    In many questions online when searching for information about digest authentication, the person asking the question is asking about…

    12 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    started  ·  2 comments  ·  IAM  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  5. Via API call invite existing atlas user & assigne them to project & teams

    in are organization we want user to have a self serve service that allow them to create project, cluster ,etc ...

    for now we can only automate half of the process, because we need the web UI to invite user & wait that they approve the invitation before assigning them to project.

    It would be great than we could, via API call, invite user & assign them to project or team without having to use manual process & wait for user to acknowledge the invitation

    thanks

    11 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    started  ·  0 comments  ·  IAM  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  6. Add Atlas users to existing teams even though the Atlas user is still pending invite

    Currently when we send invite emails for the organization we have to wait for the users to accept the invite before we are able to configure project level permissions. This often creates confusion and bad user experience; when users first sign in they are anticipating to see their projects but instead they see nothing until configuration is finalized.

    Please make it possible to add users to teams which are still pending invite acceptance so the user experience is more seamless and less confusing.

    8 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    started  ·  1 comment  ·  Other  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  7. Remove the requirement to have an API Access List CIDR before being able to manage backup schedules

    The issue is described in this github issue, specifically in the linked comment: https://github.com/mongodb/terraform-provider-mongodbatlas/issues/222#issuecomment-855905952

    Here is the requirement as described in the API docs: Remove All Cloud Backup Schedules
    Removes all cloud backup schedules for the specified cluster. "This schedule defines when MongoDB Cloud takes scheduled snapshots and how long it stores those snapshots. To use this resource, the requesting API Key must have the Project Atlas Admin role and an entry for the project access list."
    https://www.mongodb.com/docs/atlas/reference/api-resources-spec/#tag/Cloud-Backups/operation/deleteAllBackupSchedules

    Our request is that the requirement to have an API Access List to manage backup policies be removed.

    At the very least,…

    3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    started  ·  1 comment  ·  Other  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  8. Kubernetes AtlasProject backup compliance

    Extending the AtlasProject Kubernetes resource to allow management of a backup compliance policy, including setting project-wide backup schedules and enabling backup persistence after termination by default, would be a major improvement over the current experience.

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  • Don't see your idea?

Feedback and Knowledge Base