Running an App Server

May 3rd, 2026 -Ben

Running an app server isn’t enough. Eventually you’ll want to automatically restart your app if it crashes. Eventually you’ll want to be notified if it crashes. Eventually you’ll want to observe how your app is working. Eventually you’ll want to tweak settings without restarting your app. Eventually you’ll want to gracefully degrade your app when it’s stressed, so it crashes less often. Eventually you’ll want to backup data that your app is creating. Eventually you’ll want two copies of your app to handle more requests (horizontal scaling). Eventually you’ll want to expand/contract the number of running app copies. Eventually you’ll want better insight on how people are using your app. Eventually one database won’t scale vertically fast enough. Eventually you’ll want to authenticate a user to your app. Eventually you’ll want to tell another service you’ve done something. Eventually you’ll want to know when an outside service has done something. Eventually you’ll want your websockets to stay connected through redeploying your app. Eventually you’ll want healthchecks because monitoring the process isn’t enough.

None of these things are your app but they all work together to make sure your app works. They’re all capabilities around the core business logic of your app. I wasn’t an engineer during the microservice craze. I’ve been learning a lot about the graduated and incubating CNCF projects though. There’s a lot of work with initiatives like OpenTelemetry and OpenFeature that I wouldn’t want to replicate in my app. Authentication is really tough to set up all the features people may want (password, passwordless, MFA, passkey, etc). What if you had a central server you could trust (a la forward auth or OIDC)? Whole companies are built around adding these capabilities to your app. Clerk and Firbase sell auth, Datadog/Grafana/Betterstack/Sentry all sell telemetry. Vercel/Posthog sell feature flagging. If you use any of these services, are you running microservices now? Or is it still a monolith? If you run all those same things yourself – Jaeger, Prometheus, Keycloak/Authelia, flagd – are you still building a monolith or microservices?

We all agree a reverse proxy is a good idea for a web server, so you’re always going to have at least two services running. Or do you want to build TLS support directly into your app? Then how would you handle load balancing?

I’ve read DHH’s majestic monolith, but I’ve also seen them release Upright. I’ve seen them try different auth methods (all standards, but built into their app) and I’ve seen people always ask for their preferred, portable auth method. You can’t make everyone happy, but maybe you don’t need to reinvent the wheel either.

I’m not arguing or advocating for a monolith or microservices. I’m not arguing for hosting it all or paying someone else.

If you do decide to run microservices, don’t separate your business logic too much. You’ll already run a lot more services than you think.

If you decide on a monolith, don’t try to do too much. There are many standards out there and many smart people have thought through these problems. There are many self hosted projects or people to pay to take care of something you don’t care to implement. Let your app stay focused on your core business.

Whatever you call it, you’ll want many of the same parts other people use. Hopefully you’ll share something useful or fix something broken, and we can all continue to learn together. Learn the names, they help communicate the concepts. Learn the concepts and their nuances, names can’t capture every detail. If they did, we’d all have names as long as Tolkien’s Ents. Eventually someone will pay you for your discernment. You can take great pride in it and they don’t have to learn about it.