You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Users that are familiar with serverless database providers like Neon, Supabase, and PlanetScale are used to directly accessing their databases over the internet. In contrast, Nitric provisions databases inside a VPC with no public internet access for improved security. This difference can cause confusion for users who are expecting to connect to their databases directly from their local machines.
Suggestion
Add documentation explaining why Nitric databases are deployed inside a VPC without public access. Cover the benefits of this approach, such as enhanced security and reduced exposure to attacks. Additionally, provide guidance on how users can access these databases if needed (e.g., through a jumpbox/bastion host on EC2). This will help users better understand the architecture and how to work with their databases in a secure way.
Other info
This would be especially helpful for users migrating from platforms that prioritize developer convenience over production-grade security. A small section in the SQL docs, along with a link to a more detailed guide on secure database access patterns (like using bastion hosts), would be useful.
The text was updated successfully, but these errors were encountered:
Enhance documentation
Page
https://nitric.io/docs/sql
https://nitric.io/docs/architecture/sql
Issue
Users that are familiar with serverless database providers like Neon, Supabase, and PlanetScale are used to directly accessing their databases over the internet. In contrast, Nitric provisions databases inside a VPC with no public internet access for improved security. This difference can cause confusion for users who are expecting to connect to their databases directly from their local machines.
Suggestion
Add documentation explaining why Nitric databases are deployed inside a VPC without public access. Cover the benefits of this approach, such as enhanced security and reduced exposure to attacks. Additionally, provide guidance on how users can access these databases if needed (e.g., through a jumpbox/bastion host on EC2). This will help users better understand the architecture and how to work with their databases in a secure way.
Other info
This would be especially helpful for users migrating from platforms that prioritize developer convenience over production-grade security. A small section in the SQL docs, along with a link to a more detailed guide on secure database access patterns (like using bastion hosts), would be useful.
The text was updated successfully, but these errors were encountered: