Your customer portal works. Customers log in, partners see their numbers, and the back office runs its exports. The decision in front of you for the next two years is who keeps all of that running, and what happens on the day that person is not available.
Most stack discussions start with the tools and get to that question late, if at all. The order should be the other way round. The stack you can responsibly run depends on who runs it, and SunRocks is where I had to work that out for a platform I was responsible for.
What are you deciding when the portal already runs?
You are deciding who operates the application in year two, and how much operations that person or team can carry. A team with deep infrastructure know-how can run a lot. One person cannot responsibly run mission-critical software on a setup built for a team. Pick the stack after that answer, never before it.
These are the questions worth settling before anyone compares vendors, with how each one was answered on SunRocks.
| Question to settle first | How it was answered on SunRocks |
|---|---|
| Who runs it day to day, and how much of their time can it take? | One person, me, and operations could not become a full-time job next to other projects |
| What happens if that person is unavailable? | “What if I were incapacitated?” ruled out running self-managed infrastructure alone |
| Which parts stay exactly as they are? | Hasura and PostgreSQL, the core of the platform |
| What is the exit if the platform provider disappears? | Nhost is open source, so if the company ceased to exist I could somehow manage on my own |
If you are at the other end of this, holding a prototype rather than a system people depend on, what to bring a developer if you already built a prototype is the better read. And if you are still deciding whether a portal is worth having at all, our guide to self-service portals covers when one pays off.
What did the SunRocks platform look like before?
SunRocks is an Austrian electronics insurance provider, and its platform carries the daily operations: processing new policies, handling claims and everything in between. The CEO’s aim was to run the entire daily operation with just one additional employee, so the level of automation in the software was high.
By 2024 I had managed the SunRocks project for about nine years. During my time as CEO of my previous agency we kept expanding the software, most recently onto an internal OpenShift installation. This is what was running:
- Hasura and PostgreSQL at the core
- Keycloak with oauth2-proxy for authentication and authorization
- S3-compatible file storage inside OpenShift
- Node.js workers for email, PDF creation (insurance certificates) and payment, on a queue built on PostgreSQL for simplicity
- A Node.js API for business logic, triggered by Hasura events and actions
- External services: Postmark, PDF Monkey and Mollie for payment
- Three frontends: a customer portal for policyholders and a portal for sales partners, both already on Next.js, and an admin center for the back office, still a Webpack/React application with a custom build
Hardcore over-engineered and resource-intensive, of course. We had the server capacity at Hetzner and an excellent team of developers, and for a team, using the project as a technical playground was fine. For a solo operator it was a massive problem: how do you operate and develop software like this on your own without it becoming a full-time job?
Why was a managed platform the only option for one person?
My interest in Kubernetes, DevOps and cloud infrastructure was limited (I recognise its importance and have at least a good basic knowledge of it), and offering operations for mission-critical software solo is simply unprofessional. What if I were incapacitated? From my perspective a reliable platform provider was the only option.
For completeness, I looked at the alternatives:
- Running everything on DigitalOcean was too complex and felt insecure.
- Rebuilding on Supabase would have been too much work, and without Hasura my productivity would have halved.
- A regional IT company that offers application hosting looked at the setup and found it too complex.
- Nhost had everything I needed, kept Hasura at the centre, and is open source. If things went completely sideways, or Nhost as a company ceased to exist, I would not be totally lost.
Hasura was the constant from the beginning, and I did not want to go ahead without it. The open source part still checks out: Nhost’s repository is MIT-licensed and states that the whole stack can be self-hosted.
How did the move to Nhost go?
Since SunRocks already ran on Hasura and PostgreSQL, the core moved across almost untouched. Create a project, get the CLI running, study Nhost’s directory structure a bit, add the existing migrations. Up and running in two hours, with the PostgreSQL dump restored.
| Part of the platform | Before | After |
|---|---|---|
| API and database | Hasura and PostgreSQL | Hasura and PostgreSQL on Nhost |
| Authentication | Keycloak and oauth2-proxy | Nhost Auth |
| File storage | S3-compatible storage in OpenShift | Nhost Storage |
| Business logic on Hasura events | Central Node.js service | Nhost Functions |
| Queue workers | Node.js workers | Nhost Run services |
| Customer and partner portals | Next.js | Next.js on Vercel |
Replacing Keycloak with Nhost Auth was trickier. I had an export from Keycloak, and creating the users with all their permissions in Nhost Auth was quickly done. Replacing oauth2-proxy, which we had relied on to save work in the frontends, took more effort: login, password reset and page permissions all had to be built in the frontends (if you encounter the proxy on any project, run fast). Nhost’s tooling and documentation were excellent and no serious problems came up. The same went for storage.
Nhost Run was my favourite part. It lets you run your own containers next to the managed services, which is where the queue workers went. Nhost’s documentation describes it today as running “custom and third-party container services alongside your Nhost backend”.
What changed once it was live?
When you are used to having too much hardware, you get used to certain query times. The Nhost Pro plan was fine for the customer and partner portals, but exports and reports in the admin center were too slow. The Nhost dashboard lets you configure every aspect of that: more CPU, more RAM. For someone averse to DevOps that was particularly handy, because the complexity is well hidden, and the config file is tidy and understandable too. Even the client used the dashboard to create users. Nhost’s compute documentation still lists dedicated CPU and memory as a Pro plan option, set per service from the dashboard or the config file. On timing, from the starting gun (Nhost project created) to the complete migration took less than two weeks, and I worked a bit more than usual because everything had to be done quickly. Another two to three weeks went into bug fixes and data adjustments, so the whole transition took about a month. Nhost’s Discord support was invaluable in that critical phase, often answering within minutes.
If support response matters for your year-two plan, check which plan carries which channel: on Nhost’s pricing page today, Pro comes with email support and a dedicated Discord channel starts with the Team plan.
What should you take from this for your own portal?
The stack in this story followed from one answer: a single person was going to run a mission-critical platform, and that person needed operations to stay small and a way out if the provider failed. Hasura stayed because it was the core. Nhost won because it took the operations work off one person and was open source. With a larger team in year two, the same questions could have produced a different stack.
The same stack still carries our own product. Glasswise, our SaaS for wine e-labels, runs on Next.js, Hasura and PostgreSQL on Nhost.
So before you compare vendors for an application that already runs, write down who operates it, what happens when they are away, which parts must not move, and what the exit looks like.
If you have a portal, partner dashboard or back office running and you are working out who builds and runs it next, our web app and SaaS development service is the page to read. The public side of SunRocks is a separate project, and that kind of work is covered on our headless migration page.