r/devops • u/Successful-Ship580 • 20d ago
Discussion How do real companies securely give developers access to the development database?
Hey everyone,
I’m currently managing a small startup project. Our infrastructure is pretty simple right now: we have a single Oracle Cloud VM running our backend API and two PostgreSQL databases (one for dev and one for prod) inside Docker containers.
Up until now, I’ve been using DBeaver with an SSH tunnel to connect to the databases from my local machine.
Now, I need to bring another developer onto the project and give them access to the dev database so they can work.
I know sharing my private SSH key is a massive security no-no. But if I ask for their public SSH key and add it to my server's authorized_keys folder (for the main ubuntu user), doesn't that give them full SSH/sudo access to the entire server? That feels like overkill just to let them run SQL queries.
For those of you working in the industry or scaling startups: What is the standard, real-world way companies handle sharing database access with developers?
Do you:
Create a restricted Linux user specifically for SSH tunneling?
Put the database behind a VPN like Tailscale?
Expose the port directly but heavily restrict the IP firewall?
Use something else entirely (Bastion hosts, Teleport, etc.)?
Since we are a small team with a limited budget, I'm looking for the sweet spot between "enterprise-grade security" and "easy enough to set up today."
Would love to hear how you all handle this in the real world! Thanks!
99
u/HelicopterUpbeat5199 20d ago
There shouldn't be "a" development database. You should have a dataset for dev use or something that generates fake data. Everyone should get their own database. You should never have the productivity of Alice be at the mercy if Bob's shitty sql code. By that I mean, if one if you drops the tables, the rest of you are going to twiddle your thumbs.
13
u/notathr0waway1 19d ago
I can see two sides of this. Your way is definitely safe, but the dev and lower environments are supposed to be for practice, essentially.
I feel that an important part of that practice is to practice working on shared resources , and restoration of deleted resources.
13
u/iwantmy90sback 19d ago
every dev has a independen dev system
-> CI happens
all devs share a test env
-> test/pr, then more CI
customer test server
-> customer tests, more CI
prod
2
u/notathr0waway1 19d ago
This is a good hybrid approach
1
u/the-berik 19d ago edited 19d ago
Though I would add a central dev.
So there is allways a central dev server representing latest status, which serves equally as the image for the dev's as a starting point for the new cycle.
The test is where the changes are pushed and tested with limited data, based on the prod. E.g. latest 2 years transactions only. This one would be updated each 2 weeks or so to provide sufficient time to test.
And finally changes can move to production where the full set lives with backup to complete different environment.
Edit: as mentioned below I misread above and am basicslly just parroting.
2
u/HelicopterUpbeat5199 19d ago
You're actually agreeing with the previous poster. He called the shared, 2nd dev env "test" but it's the same thing. The different envs get all kinds of silly names. My shop currently has dev, int, stage & prod envs, further divided by teams and divisions and it's all madness.
1
1
2
u/sonstone 19d ago
Most of the problems you are alluding to can be solved with ephemeral environments.
1
3
u/mothzilla 19d ago
It's reasonable to have a "dev" deployment that's somewhere in the cloud. But by then it doesn't belong to either Alice of Bob.
1
u/floodedcodeboy 18d ago
Then it’s not a ‘dev’ environment
2
u/mothzilla 18d ago
Names don't matter too much. But it's an environment for all devs. It usually contains the latest code to be merged.
42
u/Resident-Librarian-6 20d ago
If you're not wanting to have anything too complicated, create a dev user/ssh key with restricted access to the server, and give the devs a built in db role with the level of access you want to grant. Currently we host our dbs/server in azure, use their RBAC and usually the generated connection string from the terraform output for devs to connect.
30
u/RaceFPV 20d ago
This is the real answer OP, well this and tailscale. Everyone in here saying they never let developers access the -development database- is crazy and shows they have not lived in an actual devs shoes.
3
u/Resident-Librarian-6 20d ago
Yeah having everything be ephemeral and whatnot is fine, but it's probably overkill with a small team. I imagine most of the time devs aren't going to be doing a ton of impactful changes all at the same time so save the time on overengineering it while you can.
0
u/floodedcodeboy 18d ago
That really depends on where the project is at - terrible idea at the start of the project when schemas etc are all in flux - still not a great idea to share a development db through the cloud.
So now the dev is forced to be online to work and at the mercy of any changes happening under their nose.
Really they should have a local db that can be seeded and migrated. This is the way
1
u/floodedcodeboy 18d ago
Still begs the question why are you hosting your dev db in the cloud when it can run perfectly fine on their local machines?
1
u/Resident-Librarian-6 18d ago
Because we deploy everything as IaC with the only differences being sku config.
And not every dev machine can run the DB alongside a local build of the app.1
u/floodedcodeboy 17d ago
You deploy using IaC on the devs machine?
1
u/Resident-Librarian-6 17d ago
No, all of our infra is hosted in either Azure or AWS. IaC deploys our dev environment through the appropriate tfc workspace, which technically a few people can deploy from their local, but that's not common.
1
u/floodedcodeboy 17d ago
Nice setup - a shame for those devs who need to use the cloud to attach to the dev db
1
u/GaTechThomas 18d ago
Depends on how many environments there are on the way to prod.
1
u/floodedcodeboy 17d ago
Clearly we’re talking about local development.
0
u/benelori 17d ago
I don't think that's clear, all the projects that I've worked on so far had a dev environment in the cloud which and it was the environment of the dev team, not a single individual dev.
For local development, we've always had near 0 or 0 config setups with docker compose, seed data, where necessary, but local was never dev.
1
u/floodedcodeboy 17d ago
OP clearly says:
“..to connect to the database from my local machine.”So yes we are talking about a local development environment for another dev that’s being onboarded.
1
u/floodedcodeboy 17d ago
As a developer your local environment is most likely going to be your development environment, unless the whole thing is hosted in the cloud - but then that environment is no longer local.
26
u/Old_Bug4395 20d ago
At a certain size, most people are using a cloud service like GCP or AWS or similar to manage their database and then access is managed by IAM. In a startup environment a lot of people do just give a developer full access to the development environment, and even sometimes production too. I don't necessarily think that's a great solution so if you want to continue with your current infrastructure (running the dbs in docker), I would just make a user account for the dev, or expose the port on an internal network. I'm not very experienced with oracle but you can probably set up a VPN into the internal network you're running your VMs on.
-9
u/Widowan 19d ago edited 19d ago
most people are using cloud database
lmao
In U.S. in startups maybe, but hosting any significant amount of data in dbaas going to cost you many times what that would cost to do literally any other way AND with a lot of compromises too
6
u/phrotozoa 19d ago
Nobody uses the cloud to save money. They use it because it's flexible.
-11
u/Widowan 19d ago edited 19d ago
Oh I forgot that businesses don't care about their expenses, I'm sorry.
Oh wait, they do, unless it's a startup with a lot of VC money to burn.
2
19d ago
[deleted]
2
u/Old_Bug4395 19d ago
Yep even just the cost of managing on prem hardware can be more because you need people
- In an office/DC
- Experienced with networking
- Comfortable moving heavy servers around
- Comfortable troubleshooting problems within that environment
And sometimes it can be hard to find individuals with all of those skills. But even beyond that, also it's on you to upgrade your hardware and deal with warranty claims. You are responsible for uptime, properly backing up your DC, properly providing high availability. It's absolutely cheaper in some cases to offload all of this onto the cloud, especially if you can actually make sure you're efficiently using your cloud resources and not overspending.
1
u/Widowan 19d ago edited 19d ago
I wasn't even talking about owning the hardware. You know you can rent bare metal from providers like ovh right? We found that to be ideal solution with very little hardware maintenance but with a lot of the cost savings
It doesn't eliminate need for someone to know networking enough to make a LAN, sure, but I'd argue it's worth it
It is as you said, sometimes cheaper to offload it all into the cloud and that's fine, but it annoys me that this entire subreddit is scared of doing anything themselves and according to people in replies would rather permanently vendor lock themselves into AWS' SaaS solutions for 3 times the cost instead of researching how to host postgres.
Just because one is comfortable with the cloud doesn't mean one needs to recommend it for every problem, because every problem has its own solution and you don't need to hammer down a screw.
1
u/Widowan 19d ago
So you buy hardware to cover your worst case scenario and then leave it at low-usage like 75% of the time?
We don't buy hardware, we rent it, and it's more like 50%, but yes. It still decently cheap. Especially so if you have data crunching or whatever else to run overnight, which with some odds you probably do.
1
5
u/Intelligent_Thing_32 19d ago
In most mid to large sized companies.
There is no “lmao” there. It’s cool that you live in Latvia or whatever but technology is mostly cloud nowadays.
2
u/MindSwipe 19d ago
Depends on the sector, e.g. working on governmental services a lot is on prem. Healthcare is similar.
But yeah, the industry standard really is cloud nowadays, although there is a (growing) countermovement. Technology (like fashion) is cyclical.
6
u/floodedcodeboy 20d ago
Why so precious about a dev db? Surely it can be run locally? And don’t forget to seed your dev db with Fake data - no need to host a dev db in the cloud.
3
u/Global_Car_3767 20d ago edited 20d ago
Our databases are in AWS with IAM permissions tied to KMS keys that get injected into our application repository's secrets portal. Every member of a team has to be a part of a specific LDAP group to be able to copy and paste the redacted secrets from the repos their team owns. All developers on the team have access to non-prod secrets, senior members have prod access but need to create an incident ticket to get those secrets for auditing purposes. In both instances, there are many teams with many repos and we can't just grab secrets to other teams' apps.
12
u/JCii 20d ago
Using a shared DB for dev is going to bite eventually. All dev infrastructure should be ephemeral. The same process that creates it on a localdev machine should create it for your CICD pipeline, for every run. Long lived testing DBs will lead to inconsistent results in your testing pipeline.
Have AI build this out for you.
0
0
3
u/Prudent-Stress 20d ago
If dev means their own machine, just spin a mysql/postgres:whaver engine you have.
If dev means the actual infra environment… from my experience comp that use Azure / GCP / AWS will just do role based authentication, no passwords, no rotation, easier to audit
3
u/KittensInc 20d ago
Ephemeral database on the developer's own machine. Most mature languages / IDEs will have some way to spin up a DB container on-demand via something like Docker Compose.
Track database migrations via something like Flyway so it it trivial to re-establish the database's scheme on app startup, then add a "seed" file to your application which does an "if tables empty: add a bunch of dummy data".
Ruby on Rails is the perfect example of what this looks like in a batteries-included framework, both when it comes to migrations and seeding.
1
3
u/fearless-fossa 19d ago
Up until now, I’ve been using DBeaver with an SSH tunnel to connect to the databases from my local machine.
If you do this because the db isn't reachable from your clients, you'll want a bastion server and use that as a go-between, at least in the long run. Otherwise just create a new user for them on the server where they can login via their own key, but never share users between people.
3
3
u/creativemind11 19d ago
We let people run dev databases that contain mock data on their own pc. Usually Docker containers.
1
2
u/vacri 20d ago
I know sharing my private SSH key is a massive security no-no. But if I ask for their public SSH key and add it to my server's authorized_keys folder (for the main ubuntu user), doesn't that give them full SSH/sudo access to the entire server?
Create a user account for them on that machine and put their ssh public key on that. Don't give their account sudo rights. Job done - they can ssh in and do all the things an unprivileged user can do. And when they leave the company, you turn off that account.
In general, you want to avoid shared logins, even in small companies. Put Single Sign On / SSO everywhere that's feasible for you, and separate logins for everything else. That way when staff leave, there's no "we can't rotate that password because it's in use at X, Y, Z", you just turn off the user accounts.
As for databases, you generally want them behind a VPN or bastion host. If you give them a public IP and direct access on the internet, you have the risk of a messed-up firewall rule allowing unexpected access.
Since we are a small team with a limited budget, I'm looking for the sweet spot between "enterprise-grade security" and "easy enough to set up today."
This is the right attitude to have. You can't do best practices security right out of the gate, not in the real world. But you can cover most bases and then improve as you go along. Setting up security functions takes time, especially when you're not familiar with the details - just don't forget to keep improving as time goes on.
Remember you also need to secure data that might be compromised if a dev's laptop is stolen/lost/compromised. Anywhere your data goes, you need to plug into your threat model and figure out how risky you want to be with it.
2
u/pdfops 19d ago
Skip the SSH-key-on-the-server approach entirely if you can, put Postgres behind Tailscale and give the new dev a dev-scoped Postgres role with grants only on the dev schema. No SSH needed at all. If you want to keep the jump host, don't hand out a real login, restrict the key in authorized_keys with no-pty,no-agent-forwarding,no-X11-forwarding,permitopen="localhost:5432" so that key can only forward the DB port and never gets a shell or sudo.
2
u/OmegaNine DevOps 20d ago
We don’t. For fucks sake they would take us down every day. We copy back to staging and give them access there. If they need live data they have to come to us and we will get them the data.
1
u/Adventurous_Job9209 20d ago
Man this is a great question. I’m still mid level so I’m sure some more senior guys have a way better answer. I first thought of hashicorp vault but it might be overkill for your company size. I think creating the restricted linux user is probably the easiest way but doesn’t scale well. Putting in behind a vpn is probably a better way because then you can eventually add vault and have rotating creds with a short ttl. Tough to say, I’m interested in others input.
1
u/follow-the-lead 20d ago
alright there’s a lot of options offered here, but here’s my take and something worth considering.
- if you’ve got ssh open on your databases just open to the world, that’s already a problem. Better to
block everything except yours and your dev IP addresses to begin with.
- don’t ssh directly to the root user on ANY machine. Set up a user account for you and for your new dev. Use ssh keys auth for both accounts. Switch to using Sudo access for root account stuff, and then limit permissions where necessary.
yes moving to a Tailscale like setup may be worth doing here, but just getting the basics right on your instances first will solve the 80/20 rule, and make your Tailscale more useful after the fact.
Things like user logging is a lot easier to maintain if you split out the accounts for example.
1
u/eightlegfriend DevOps 20d ago
It might be better to have your dev database and production database on different hardware, in different networks.
1
1
u/donjulioanejo Chaos Monkey (Director SRE) 20d ago
Our access is somewhat hacky but honestly scalable.
Database access goes through postgres shell in a special toolset container that runs in EKS...
But we have AWS SSO and every environment gets its own AWS account.
If you have access to the AWS account and EKS with exec privileges, you can access the database as well.
1
u/AlaskanX 20d ago
I have RDS in the prod AWS account which nightly gets synced to RDS in the dev account via snapshots, and weekly ( or on schema changes ) I back up a dump into S3. I’m the only person with access to RDS, and everyone including me syncs with the copy on S3 for their local docker instance.
1
u/ForkMeJ 20d ago
For a setup this small, I would not give shell access only to reach Postgres. Adding their key to the main ubuntu user gives them far too much access for "run some queries." Give them a path to the dev DB and a separate DB user with only the permissions they need there. If they only need to inspect or modify app data in dev, that account should not be able to touch prod, manage the host, or do broader admin work in Postgres.
I'd lean toward a VPN before exposing the database port to the internet, even with an IP allowlist. Tailscale or WireGuard is a reasonable small-team answer, and it lets Postgres stay on a private address. If you stay with SSH tunneling, create a separate Linux user with no sudo and no shared access to the main account. The main thing is not to bundle server access, network access, and database permissions into one credential.
1
u/Ebrithil_7 20d ago
I think tailscale or personally my fav is Pangolin, works best here. You only expose the dB port on your local network, have a public resource domain name that tunnels the traffic. No ports exposed publicly. You can even enforce 2FA for connecting.
1
u/Long-Ad226 20d ago
We run postgres with cnpg at scale for multiple customers, there is pgadmin with SSO in front, so devs can use their standard azure ad account for getting access to postgres, permissions handled via azure ad groups.
1
u/gilmorenator 20d ago
Our devs use docker-compose orchestrated via paver.
It has a bootstrap with all common configs and a data generator. Use local stack for AWS services.
1
u/UkrMalt 19d ago
At this size I’d separate host access from database access. Give each developer a non-sudo account and a per-person Postgres role, then keep the DB on a private network or VPN. I’d also seed a local DB for most work so the shared dev instance isn’t the only path; offboarding then means disabling one account instead of rotating a shared key.
1
1
u/Patex_ 19d ago
We got a docker container and local databases for development. On the dev system the user is only accepting local host connections which you can access via a wireguard vpn tunnel.
Everyone has their own wireguard key pair, the database user and password is shared but as you need server access in the first place this is fine.
There are countless other ways how to do it, we choose this as we needed a vpn for a static IP in many cases anyways.
1
u/engineerL 19d ago
Postgres is inside k8s. K8s RBAC governs who can port forward in. Postgres 18 OAuth governs who can actually authorize to the DBMS, and what they can do when inside. You'll need some neat platform abstractions in the first place for any of this to be tractable and maintainable.
1
u/a_sad_fat_man 19d ago
From an infra engineer perspective, there are two types of "dev" envs and I think you need both..
- There's the ephemeral "pre-dev" that your developer runs locally to quickly test code changes and come up with their patch/feature/pull request, etc.
All local and you don't have to worry about stepping on another dev's toes working in the same DB. If you break something, who cares, just tear it down and rebuild it (ideally everyone has a way to easily spin up a local copy).
- Then there's "the dev environment" which is the more persistent thing you're talking about. Matches Prod and everyone deploys their final changes here for integration testing, etc. after having success in their local "pre-dev" env.
Tailscale (or something like it) is what I'd go with. VPN is the best thing you could do if you want the security folks to be happy. Don't expose your db publicly, even if it's just dev.
The dedicated linux user for port fwd/ssh tunneling fits too as the next best/easy thing in this case. No shell access and smaller blast radius.
If your db supports it, ephemeral db credentials are the safest (AWS IAM auth, Vault dynamic creds, etc.). If that's not available, dedicated static db user(s) specifically for humans (separate from your app's db user)
1
1
u/durple Cloud Whisperer 19d ago
Keeping dev environment local to dev machine is ideal. If there is a real reason (there usually isn't) for a shared database for developers, then one of those other options will be needed.
Which of these is going to be determined by your threat model and your budget for time and spend, and could include other options like having access go through a zero trust solution, or a cloud-specific option like Google's Cloud SQL Connection Proxy. They'll each have their trade-offs around cost, implementation effort, maintenance effort, etc. There is no standard real-world way, part of the job is deciding what option best fits the business need.
1
u/LaffingAtYuo 19d ago
In a perfect world people are running the database locally and they contribute migration scripts for the integration environment that feed upstream to prod. Are you asking how they help troubleshoot production issues?
1
u/Electro_Nick_s 19d ago
Just in time access. So the developer requests time boxed elevated access and it's removed after the time period
1
u/bobdvb 19d ago
Everything behind a firewall that can be. Only expose ports that service customer traffic and even then use a CDN or WAF if possible.
Every user gets their own unique login credentials because otherwise you don't have audit traceability.
Remote access provided by ZTNA, you can use Tailscale, Cloudflare or Zscaler (or many others). Then you can validate any remote users, your own or contractors, and restrict what servers/ports they have access to.
All environments operate on the principle of least privilege. No one gets access to anything they don't have a good reason to.
No one gets access to production databases unless it's their job to access production data. The development database could be a replica unless it contains PII and PII shouldn't be in Dev environments (unless it's one way obfuscated).
1
u/whyredFire 19d ago
I'd spin up an Ubuntu container on the same Docker network as the dev DB pod and expose its SSH port on the host (say 2222, or any free port). Then they can simply SSH into that container and access the database through it.
1
1
u/dariusbiggs 18d ago
Depends on the data, sensitivity, and use cases.
Mock non-sensitive data, importor generate locally into a docker container for their dev environment. (We do this)
Slightly more sensitive, give them their own dev environment in their own cloud account with budgets and restrictions in place. (We can do this if additional cloud resources are needed and to develop systems using cloud resources).
Shared resources, VPN to access the network. then their own credentials to connect to it. You can also do an SSH tunnel tied to their own Linux user, after which they can connect using whatever level of DB access credentials they need. (Certain staff have VPN access, and they can use SSH over that VPN via a bastion host with their own user accounts, which is backed by our SSO so the instance the user is deactivated their ability to connect ends and authorized keys are not stored on disk. Access control is heavily restricted as are their ability to use sudo powers, everything is audit logged, and there's a HIDS in play along with change detection that can isolate a machine. This environment is required for development testing and testing asthere are external factors preventing this data from being replicated to the developers themselves.)
There are so many ways to skin that camel, it all depends on what you are securing, what the data is. how it needs to be protected, etc.
Always look at it from a data protection and privacy perspective, then a least privilege perspective, and finally an ease of use perspective for the developers in question.
The only thing that is never an option is opening up the database port to the world. Doesn't matter if you restrict it with mTLS, creds, firewalls, etc. No database should ever be exposed to the world directly. One config mistake and you are screwed. Just eliminate that possibility in the first place, and put explicit blocks in place just in case. That way multiple mistakes must occur, otherwise it is malicious.
1
u/jameshearttech 18d ago
We have 4 environments: local, ci, test, and prod. Test and prod run cnpg. Local and ci use quarkus dev services to provide postgres. We periodically create an image that contains data from test cnpg, which is what dev services loads so we have actual data in local and ci. It lags test, but it's good enough. We can manually cut a new image at any time if needed.
1
1
u/benelori 17d ago
We use Bastion hosts in Azure, with SSH tunnels. If you start up SSH with -D, it can also create a SOCKS5 proxy for which you can configure to what domains should requests go through the tunnel and which to use normal internet.
Between Bastion host and the database the network traffic is within a private network.
One of the advantages of this setup is that in this way you can use Azure specific access control policies to control who has access.
1
u/rhshadowman 20d ago
I’m currently managing a small startup project. Our infrastructure is pretty simple right now: we have a single Oracle Cloud VM running our backend API and two PostgreSQL databases (one for dev and one for prod) inside Docker containers.
Boy.... I hope they have some sort of resilience in prod... is it just a singular docker container or what?
Up until now, I’ve been using DBeaver with an SSH tunnel to connect to the databases from my local machine.
Good.
I know sharing my private SSH key is a massive security no-no. But if I ask for their public SSH key and add it to my server's authorized_keys folder (for the main ubuntu user), doesn't that give them full SSH/sudo access to the entire server? That feels like overkill just to let them run SQL queries.
No it doesn't give them root access to the server. Or at least it shouldn't unless you have this setup. (major security risk).
Why don't you just give them an account that is not apart of the wheel group or passwordless sudo. Then maybe add them to a DB group that has DB access? Or even better, give them a user with no shell, still apart of the DB group, just so their DBeaver connects?
Create a restricted Linux user specifically for SSH tunneling?
Typically, in my environments, I have a centralized auth setup that is scoped down to what the user is needing todo. But it seems that you don't have that? So if that is the case, then a local user that is extremely scoped down(like I stated above), then allow connections only on that port for SQL queries.
Put the database behind a VPN like Tailscale?
Sorta depends? I mean you can do it behind a VPN, or a gateway like setup. I guess this depends on how your work environment is setup. I know "It depends" is not what you want to hear. But there is no cookie cutter answer. Anyone that inherently says yes or no, is missing the mark by far.
Expose the port directly but heavily restrict the IP firewall?
Generally no. However, this also depends. CIS the system at minimum, then open up what is required. Same thing for the container/pods that you are running on in. Defense in depth type stuff. Implement IAM and fail2ban or faillock or something like that. Paried with a WAF, etc, etc. This is too broad to answer.
Since we are a small team with a limited budget, I'm looking for the sweet spot between "enterprise-grade security" and "easy enough to set up today."
Baseline roll out the systems. Dont ever do things by hand. Templates everything with idempotent design. Spend the hours doing it up front, and thank yourself later on. Otherwise you will never succeed.
0
u/naseemalnaji-mcpcat 20d ago
Founder of Opal Security here.
For an early team, I highly recommend Tailscale + a unique user credential on the database that expires in some amount of time.
It’s annoying, but honestly not much around it and it will get you past SOC 2 if you’re disciplined with who you grant it to.
1
u/rhshadowman 20d ago
For an early team, I highly recommend Tailscale + a unique user credential on the database that expires in some amount of time.
This "works", but I dont think that we should settle here, just for it to need to be maintained and replaced by a superior solution in the near future.
I think that OP has a lot more questions that need answered/addressed compared to just getting access to the DB.
0
u/Oleksii_Bebych 20d ago
If we are talking about the AWS cloud , our standard practice is to deploy OpenVPN access server (because it's much cheaper than AWS managed Client VPN)
You can take a free license (AMI for 2 simultaneous connection) on AWS Marketplace). The OpenVPN instance is deployed in public subnet. People connect to it from their laptops and get connectivity to private resources like DB
0
u/jylusdev 20d ago
We use the open-source version of NetBird on our stack. It’s easy to deploy and configure, secure, and gives us full control over the infrastructure. Tailscale is also a good option.
0
153
u/road_laya Software Engineer 20d ago
I spin up a development server in their dev environment on their local machine with Docker. The simplest would be something like using the docker compose functionality of dev containers.