I'm running a small startup project on a single Oracle Cloud VM. The backend API and separate development and production PostgreSQL databases run in Docker containers. At the moment, I connect to the databases from DBeaver through an SSH tunnel.
I'm bringing another developer onto the project and need to let them work with the development database. I know sharing my private SSH key is unsafe, but adding their public key to the main ubuntu user's authorized_keys file also seems excessive if it potentially gives them broad access to the server.
What is the normal real-world approach for a small team? Should I create a dedicated Linux account restricted to port forwarding, put the database behind a VPN such as Tailscale, expose the database only through a tightly controlled firewall, or use something like a bastion host or Teleport? I'm looking for a setup that is secure and maintainable without adding unnecessary enterprise complexity.
5 Answers
A good starting point is a separate Linux account for the developer, using their own SSH public key. Do not add the account to sudo or any administrative group, and configure it for tunneling only if possible—for example, disable shell access and restrict forwarding to the development database port. PostgreSQL should also have a separate role with only the permissions they need. Never share your private key or a common administrator account.
Before expanding access, make sure production has tested backups and some resilience. A single VM running both application and database workloads is a bigger operational risk than the choice between a VPN and an SSH tunnel. For the immediate setup, a non-sudo tunnel-only user plus a limited PostgreSQL role is practical; add a private VPN and infrastructure automation when the team or compliance requirements justify it.
For a small team, a private network overlay such as Tailscale is often the easiest long-term option. Keep PostgreSQL bound to the private interface, allow access only over the VPN, and give each person an individual database credential. Expiring or regularly rotated credentials make offboarding much easier. This avoids exposing the database directly to the internet while remaining simpler than building a full access gateway.
Developers often do most of their work against a PostgreSQL instance running locally in Docker or a disposable per-developer environment. Keep a shared development or staging environment for integration testing and deployment checks, rather than making everyone depend on one database. A shared database can be accidentally reset or altered, causing conflicts and making tests unreliable.
They may still need access to the shared environment for integration testing, but local databases should cover normal development wherever possible.
Regardless of the access method, separate accounts are important. Use individual operating-system and database identities, log access, and grant the development role only the permissions required. Avoid direct database exposure to the public internet; a VPN, restricted bastion, or tightly constrained SSH tunnel is preferable. Production should be isolated, with read-only access at most, while changes go through migrations or an approved deployment process.
That is a reasonable starting point, but document and automate the access process so it does not become a manually maintained exception as the team grows.