Skip to main content
The topic is a common question from security teams accustomed to traditional “on-premise” or “flat-network” architectures. In a traditional setup, a database password is the primary (and often only) line of defense. In a modern, cloud-native architecture like Upsun’s, we use Identity and Network-Based Security, which is fundamentally more robust than a simple shared secret (password). Quick summary: Our platform is built on a Security by Design philosophy that prioritizes network isolation and explicit authorization over shared secrets, which are often a point of vulnerability. By removing the default database password, we remove the risk of that password being leaked, hardcoded in scripts, or checked into version control. Instead, we rely on cryptographically secure SSH keys and network isolation, ensuring that your data remains private and accessible only to the applications and users you have explicitly authorized. Here is a more comprehensive breakdown of why our default configuration is not only secure but often superior to traditional password-based setups. Network isolation principle

​
1. Zero External Exposure (No Public Route)

The most common reason for a database breach is a database being accidentally exposed to the public internet. On our platform, databases have no public IP addresses and no route to the outside world. The database service runs in a private, isolated virtual network. There is no “front door” for an attacker to knock on, meaning brute-force attacks or credential-stuffing attempts against your database are architecturally impossible from the outside.

​
2. Multi-Layered Logical and Physical Isolation

We utilize a defense-in-depth approach to ensure that your data is siloed:
  • Environment Isolation: Every environment (Production, Staging, Dev) is fully isolated. We use Linux namespaces, seccomp, and cgroups to ensure that processes in one environment cannot see or interact with another.
  • Project Isolation: Each project is restricted by strict filtering rules. Communication between two projects is only possible via public APIs/Web requests; they cannot “talk” to each others’ internal services.

​
3. Explicit Service Authorization (The “Need-to-Know” Principle)

In a traditional network, if an attacker gains access to any server, they can often “scan” the internal network for other services (like a DB). In our architecture, nothing is accessible by default. For an application to talk to a database, the connection must be explicitly declared in the configuration. If the relationship is not defined, the network routing literally does not exist between those two containers. This implements a “Zero Trust” model within your own cluster.

​
4. Secure Administrative Access via SSH Tunneling

When a human developer needs to access the database, they do not connect to the database port directly. Instead, they must use a secure SSH tunnel.
  • This requires SSH Key-based authentication, which is significantly more secure than a standard password.
  • The user must have explicit permission (RBAC) to access the environment via the CLI.
  • The tunnel encrypts the data in transit and ensures that only authorized, authenticated users can bridge the gap between their local machine and the private network.

​
5. Compliance and Third-Party Validation

Our security model isn’t just a theoretical preference; it is audited and validated by leading global security standards. We maintain compliance with:
  • PCI DSS: For handling payment card data.
  • SOC 2 Type 2: For operational security and data privacy.
  • ISO 27001: For information security management systems.
Numerous highly regulated organizations across financial and consumer sectors have conducted deep technical due diligence on this architecture and have verified that it meets or exceeds strict internal and global security standards.

​
6. Flexibility: Optional Password Generation

While we believe network isolation is a stronger security primitive than a shared secret, we recognize that certain organizational policies or specific application requirements may still require a password. The platform remains flexible: if your security policy mandates a password, you can explicitly enable password generation for your MySQL/PostgreSQL services as documented here.
As organizations continue to evolve their security strategies, moving beyond traditional password-based protection is becoming essential. Solutions like Upsun leverage network isolation to offer a robust alternative, reducing the risks associated with credential leaks and unauthorized access. However, true security is never about a single solution — it’s about building multiple layers of defense. By combining network isolation with other best practices, you can create a resilient environment that protects your data from emerging threats. Now is the time to evaluate your own infrastructure and consider how these principles, as implemented by Upsun, can help you stay ahead in the ever-changing landscape of cybersecurity.
Last modified on April 14, 2026