468 results found

1. Create Atlas UI Triggers Programatically

   Currently, a trigger which gets displayed on the Atlas UI (under Data Services > Triggers) cannot be created programmatically, they may only be created by clicking through the Atlas UI.

   The triggers created from the Atlas UI automatically creates a new realm app named "TriggersRealmApp" even when a realm app with the same name already exists. There is no way to have any of the triggers created under any other realm app displayed in the Atlas UI. The only way is to create them under the auto generated "TriggersRealmApp" which gets created after the first trigger from the Data Services > Triggers Atlas page.

   Currently, a trigger which gets displayed on the Atlas UI (under Data Services > Triggers) cannot be created programmatically, they may only be created by clicking through the Atlas UI.

   The triggers created from the Atlas UI automatically creates a new realm app named "TriggersRealmApp" even when a realm app with the same name already exists. There is no way to have any of the triggers created under any other realm app displayed in the Atlas UI. The only way is to create them under the auto generated "TriggersRealmApp" which gets created after the first trigger from the… more

   6 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

2. Deletion Protection

   Customer suggested protection from Cluster deletion similar to AWS RDS

   https://www.amazonaws.cn/en/new/2018/amazon-rds-now-provides-database-deletion-protection/

   TL;DR - a notification when a user tries to delete a cluster, that "this cluster is protected, if you need to delete please visit the console to enable deletion"

   This would be a critical piece of functionality where roles/permissions are not sufficient.

   6 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. Cancel restore

   There should be an option to stop once the restoration is given. Or there should be an option to revert a backup restore. This is required because we can restore an old production back up to Production only. If by mistake we do that we should be able to revert back.

   6 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. Add the possibility to add a description for IP's in access control list for API keys

   In the Atlas UI, allow to add a description in the IP's allowed to use an API key. This may improve security and ease management as it allows to easily maintain this list up to date.

   6 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

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

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. Support Private Endpoint TO customer's VPC/VNet

   This would allow a Private Endpoint to connect FROM an Atlas Project TO a customer's VPC/Vnet (using AWS PrivateLink or Azure Private Link), for accessing private services like a private webhook for alerting, LDAP, and/or KMS

   6 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

6. MongoDB Atlas Provider for AWS CDK

   We use AWS CDK to deploy our infrastructure. Currently there is only a Terraform provider available to automate the MongoDB Atlas deployment. We would like to have such a provider also for AWS CDK.

   In a first step this provider should support:
   - mongodbatlascluster create, edit and delete clusters
   - mongodbatlasdatabaseUser create and remove users

   Later full feature set like in Terraform should be supported.

   Currently we use a self written provider. But this has hundreds of lines of code and means a lot of maintenance effort. For our teams this additional effort can be a reason to favor AWS DocumentDB/DynamoDB over MongoDB.

   We use AWS CDK to deploy our infrastructure. Currently there is only a Terraform provider available to automate the MongoDB Atlas deployment. We would like to have such a provider also for AWS CDK.

   In a first step this provider should support:
   - mongodbatlascluster create, edit and delete clusters
   - mongodbatlasdatabaseUser create and remove users

   Later full feature set like in Terraform should be supported.

   Currently we use a self written provider. But this has hundreds of lines of code and means a lot of maintenance effort. For our teams this additional effort can be a reason to… more

   6 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   5 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

7. OCSP stapling support for Atlas Clusters

   What is the problem that needs to be solved? As a user (MongoDB Driver) you'd like to check revocation status of X.509 certificate via TLS Certificate Status Request extension (also known as OCSP stapling) instead of doing outgoing HTTP connection to OCSP endpoint from a user (MongoDB Driver) side.

   Why is it a problem? (the pain) MongoDB Server v. 4.4.X introduces OCSP stapling functionality, however OCSP stapling is not enabled on Atlas Clusters with MongoDB Server v. 4.4.X.

   6 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

8. Allow multiple private endpoints (Private Link Service) per region in multi-region cluster

   Some situations require multiple private endpoints (using the Private Link service) to be created per region. This is not currently supported for multi-region replica sets.

   One scenario is especially for when there is a shared VPC/VNet for initial transit from on-prem to cloud plus another VPC/VNet for an application. Both of those VPC/VNets would want a Private Endpoint to connect directly to the Atlas cluster. Even if it is possible (sometimes is not), routing traffic via multiple VPC/VNets would mean 3 hops to Atlas from on-prem

   6 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   2 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

9. LDAP Authentication: Allow Private Endpoint to the customer

   Currently, LDAP Authentication from Atlas to a customer's LDAP service can go via the Internet or via VPC peering. In lieu of VPC peering, I propose using a Private Endpoint FROM Atlas TO a customer VPC that hosts the LDAP service.

   NOTE: This would NOT be using the same Private Endpoint connection that Atlas currently supports today, which allows customers to reach their clusters privately (Customer -> Atlas).
   This would be an additional Private Endpoint in the other direction (Atlas -> Customer).

   Advantages of using Private Endpoint vs VPC peering:
   * Security: The customer VPC is not exposed to Atlas, just the LDAP service
   * Configuration: The customer won't need to verify that the Atlas VPC CIDR doesn't conflict with the customer CIDR
   * Scalability: Each Project requires a separate VPC peering connection which makes for a difficult situation with having to configure each Project VPC CIDR to be non-overlapping. In contrast, the same LDAP Private Endpoint can be shared to multiple Project VPCs.
   * Complexity: Configuring a Private Endpoint is less complex than a VPC peering connection, both for Atlas and for the customer.
   * Routing/security groups: The customer does not need to configure VPC routing, nor do they need to configure security groups to protect resources in the VPC

   In AWS, the customer LDAP service would need to be hosted as a Network Load Balancer. The good news is that NLB targets can be hosts in AWS or in a customer data center.

   Currently, LDAP Authentication from Atlas to a customer's LDAP service can go via the Internet or via VPC peering. In lieu of VPC peering, I propose using a Private Endpoint FROM Atlas TO a customer VPC that hosts the LDAP service.

   NOTE: This would NOT be using the same Private Endpoint connection that Atlas currently supports today, which allows customers to reach their clusters privately (Customer -> Atlas).
   This would be an additional Private Endpoint in the other direction (Atlas -> Customer).

   Advantages of using Private Endpoint vs VPC peering:
   * Security: The customer VPC is not exposed to Atlas,… more

   6 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

10. Support for Azure VNet Gateway Transit

    Azure VNet Peering is currently very limited as access is only possible from the VNet that is peered.
    Could you please support access from onprem via private network (Express Route or S2S VPN) and Gateway Transit.
    Maybe another way to achieve the same could be via "Private Endpoint".

    6 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

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

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

11. VPC management at the organization layer (cross-project VPC) in addition of projects layer

    In order to match with GCP Host project/service projects mechanisms (network resource is managed by the host project and used by its service projects), which is usefull for companies having a large number of GCP projects to manage, in different business units, it could be very usefull to be able to not manage VPC inside projects only, but also at Organization layer: an Atlas admin could create an "organization level VPC", and peer it with a GCP host project, and several Atlas projects could 'consume' this VPC, by running clusters in it.
    That would permit to avoid having to create plenty of VPC (one per Atlas projects) and establish many peerings, what is technically limited anyway.

    In order to match with GCP Host project/service projects mechanisms (network resource is managed by the host project and used by its service projects), which is usefull for companies having a large number of GCP projects to manage, in different business units, it could be very usefull to be able to not manage VPC inside projects only, but also at Organization layer: an Atlas admin could create an "organization level VPC", and peer it with a GCP host project, and several Atlas projects could 'consume' this VPC, by running clusters in it.
    That would permit to avoid having to create… more

    6 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

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

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

12. Viewing Collection Pages

    Would like the option to view collection pages by 10, 20, 50, 100. Along with ability to move to (<first) (last>). Similar to mLab

    6 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    4 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

13. M30 Cluster Tier option with 4 CPUs

    There is a gap in the Cluster Tiers for clients that have high CPU requirements but lower disk space requirements. We run on a M30 Cluster where we max out the CPU when running aggregations, we use little of the available disk and do not want to move to a M40.

    6 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    4 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

14. Expose the `indexStats` action when creating custom roles in Atlas UI.

    The $indexStats aggregation pipeline allows user to get the statistics regarding the use of each index for the collection. This aggregation pipeline requires the indexStats diagnostic action.

    However, currently Atlas UI doesn't expose this action when creating custom roles. It would be nice to have this action listed in the "Collection Actions => Diagnostic Actions" list.

    6 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

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

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

15. Add support for arbiters

    We have a situation where we are required to build in an AWS region that only has two AZs (ca-central-1). In addition, there are no other AWS regions in the country (Canada). And due to our requirement around data sovereignty, we can't host this data set within a different country.

    Because of this, we can't guarantee our cluster will stay up if we lose a single AZ unless we put an arbiter in a 2nd region (since no data is copied to the arbiter). However, Atlas does not support arbiters currently. I know arbiters aren't ideal, but in this edge case, it would benefit us. With our non-Atlas MongoDB cluster we can support this model, but with Atlas, we cannot. And this may keep us from moving this particular cluster into Atlas until it is supported.

    Let us know if you have any questions.

    Thank you!

    We have a situation where we are required to build in an AWS region that only has two AZs (ca-central-1). In addition, there are no other AWS regions in the country (Canada). And due to our requirement around data sovereignty, we can't host this data set within a different country.

    Because of this, we can't guarantee our cluster will stay up if we lose a single AZ unless we put an arbiter in a 2nd region (since no data is copied to the arbiter). However, Atlas does not support arbiters currently. I know arbiters aren't ideal, but in this edge… more

    6 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    2 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

16. Altas CIDR ranges for network containers are too restrictive

    Background:
    For each MongoDB Altas project, the clusters built in that project are built using a "network container", which tells MongoDB Atlas which pool of IPs it can select from given a CIDR range for its underlying infrastructure.

    AWS minimum imposed CIDR value/subnet size: /28
    MongoDB minimum imposed CIDR value for clusters deployed to AWS: /24

    Azure minimum imposed CIDR value/subnet size: /29
    MongoDB minimum imposed CIDR value for clusters deployed to Azure: /21

    For customers who elect connecting to MongoDB Atlas via VPC peering, they know that IP space is a scarce resource. Reserving /24 or /21 IP space from IPAM does not scale when your project footprint in MongoDB Atlas grows sufficiently large.

    Attempting to combine projects into a single cohesive project for utilizing the larger IP space (as MongoDB likely intended) does not scale either. There is a soft cap on the amount of clusters which can be deployed to a project (25). The cap can be raised but concerns with monitoring, backups, and visibility into all clusters in the project becomes a concern, as well as further complicating billing and RBAC management in larger orgs.

    For customers with smaller deployments, like simple 3 node replica sets in AWS, MongoDB asking us to allocate a bare minimum of /24 (255 IPs) when only 3 IPs are needed, thats a ton of overhead on IPAM that goes to waste unnecessarily. The problem is even more exaggerated for 3 node replica sets in Azure, where the bare minimum network container size Atlas is /21 resulting in over 2000+ IPs going to waste.

    Proposed solution:
    MongoDB raise the minimum required network container size to /28 for all projects.

    Thank you

    Background:
    For each MongoDB Altas project, the clusters built in that project are built using a "network container", which tells MongoDB Atlas which pool of IPs it can select from given a CIDR range for its underlying infrastructure.

    AWS minimum imposed CIDR value/subnet size: /28
    MongoDB minimum imposed CIDR value for clusters deployed to AWS: /24

    Azure minimum imposed CIDR value/subnet size: /29
    MongoDB minimum imposed CIDR value for clusters deployed to Azure: /21

    For customers who elect connecting to MongoDB Atlas via VPC peering, they know that IP space is a scarce resource. Reserving /24 or /21 IP space… more

    5 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

17. Atlas project capacity should be discoverable

    Atlas project capacity should be discoverable. Based on documentation, it seems project capacity is dependent on various factors and can be arbitrarily increased via support request. We currently do not know how many clusters/nodes we have available to deploy in a given project and that is critical information to inform planning at scale.

    5 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

18. Lock a user account

    We have an occasional need to disable/lock an individual database user. Either because of a run away process or inactivity. We do not want to change the password or drop the user as we may need to reenable the user quickly with the same permissions and password as before.

    5 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

19. Add more information to "We are deploying your changes..." blue bar

    Occasionally we see the deployment blue bar but aren't sure exactly what is being done. It would be very useful to have a link to click to see what changes are currently being pushed out.

    5 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    2 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

20. Add Cluster name to process list api

    Currently the processes API (https://docs.atlas.mongodb.com/reference/api/processes-get-all/) returns only the ReplicaSet name of the process not the cluster name, while the cluster API (https://docs.atlas.mongodb.com/reference/api/clusters-get-all/) returns the replicaset name only in the MongoDB URI.

    If you have multiple clusters in the same Atlas project and you list the processes is difficult to make an association between MongoDB processes and the Cluster (Atlas UI name)

    Would be nice to have also the cluster name in the processes api

    5 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close