How to structure Next.js app so that it is installable/deployable as-is, by anyone in the community?

[lancejpollard]

Summary

Don't know how to concisely write the title 😂, but basically, I am thinking of making a Next.js app so that any user that is not part of my org (i.e. "anyone" in theory) can just deploy it and set some basic ENV vars in their Vercel settings. Something like that.

The thinking is, for example building a generic SQL database admin panel UI tool which connects to some PostgreSQL db on the backend let's say (wherever it's hosted). And just by deploying this pre-built Next.js app to Vercel, they get a full DB admin panel basically. You could do this for lots of things, having prebuilt apps which don't need modification other than config settings (like ENV vars).

What is the best way to architect / accomplish this?

Initial Thoughts on Solution

Initial thoughts on how to solve this are basically:

1. Create a @myorg/my-prebuilt-nextjs-app package, hosted on npmjs.com, which is a full Next.js app.
2. Somehow install that on Vercel? Nope, don't see how to do that. Would have to add app as package.json dependency and expose the key folders and stuff I guess, potentially, so it looked like a Next.js app? Not sure if it's worth going down this road.

Trying again...

1. Build a "library" npm package, instead of a Next.js "app" package. The library would have the page components and Next.js config settings exported and ready to go.
2. Add such library to your package.json.
3. Create your URL structure to expose the key pages. No that doesn't seem right, the URL structure should not have to be rewritten per-app. It should come as-is.

So that would get kinda cumbersome, having to build a library package (1), and a test Next.js app (2), which imports the library, to test deploying it and whatnot.

Both of these half-considered approaches seem like they wouldn't work, or would be tedious/repetitive for each app.

Is there a way to basically just have the full Next.js app as an npm package, and just deploy that as is to any Vercel account? If so, how might you structure things at a high level?

Other Thoughts

Maybe you could just have the Next.js app as a package, such as in @myorg/my-prebuilt-nextjs-app, and then somehow use a vercel.json custom script to install and symlink everything, or instead of symlinks, just copy stuff around? Ah no, that wouldn't work b/c of Vercel's file-system ephemerality stuff, etc.. Also seems complicated to deal with.

Or maybe, does it just require me building a @my-org/generate-my-prebuilt-nextjs-app, an app generator, which just creates a new Next.js app, copying the folder/file structure from a template? Also has pros/cons....

Question/Goal

Just looking for a decent way to approach this, to accomplish the goal of creating an easy-to-install default UI or whatever, for a common problem, like hosting your own Prometheus analytics UI or whatever, like any of these web interface apps you usually plop under a subdomain on your site.

Tool	Purpose	Notes
Grafana	Visualization and dashboarding for Prometheus, Loki, Tempo, etc.	Not pure JS, but can be embedded via iframe/React wrapper; the standard UI for Prometheus
Kibana	UI for Elasticsearch/OpenSearch; logs, metrics, traces	React front-end; strong JS ecosystem integration
Chronograf	Admin UI for InfluxDB (time-series metrics)	Pure JS front-end, Node build; good for Influx setups
OpenSearch Dashboards	Open-source fork of Kibana for OpenSearch	Compatible with Elasticsearch plugins
Prometheus + Prometheus Console Templates	Built-in web UI for queries/alerts	Minimal; often paired with Grafana for rich visuals

How might you do that? What are some ways?

[icyJoseph]

A GitHub repo? they fork it, login to Vercel with Github, and deploy it? Provide sensible defaults/fallbacks, for env vars, and for those that can't be defaulted clearly print which ones are missing, give instructions on how to get them. The Vercel dashboard has a pretty nice interface to add these values.

[lancejpollard]

Forking is one way for sure, but the problem is that they have to then stay in sync. It would be nice if they didn't have to manually stay in sync with the main repo.

[icyJoseph]

github actions can detect PRs being merged, or releases on upstream and re-apply them, at least copy the PR back to the fork - I've seen that, and that in turn can trigger a Vercel re-build+deploy