I hope you don't.
Let's assume that cost is paramount. There is no money for a second server. Then the question doesn't apply as you cannot use more than one server. So the cost of a second server must be okay.
Then why wouldn't you take the opportunity to automate the setting up and administration of more than one machine? Then use the development environment with multiple machines as a test place to practice high availability, DR and how to run systems spanning multiple machines.
Are you intending to run more than one server in production with automatic failover when machines die but are not going to set that up in development? How do you know that automation will every work in production if you haven't practised in development?
With devops having development, or test, not behave like production always leads to problems. Nothing quite work first time in production so isn't automated, and production is never "fixed" as we don't feel the pain in development, so we just release less often to space out the pain, which isn't at all the spirit of devops.
Have the ambition to learn everything that you will do in production by practising making development like production, feel the pain of that, and change production until there is no pain doing the same things in development. You don't have to have the entire scale of production in development as that would be expensive, but at a minimum two servers that you can easily shift things between, or run a service across as highly available, is a huge leap over having a single server.