Thread parent’s approach is what I would use as well. It makes lot of sense to isolate something as sprawling and with as large an attack surface as nextcloud… but that implies you can’t use it for public sharing. Any use that that DOES involve public sharing creates an incentive to choose a smaller and more auditable codebase (not that you’ll necessarily audit it yourself, but simplicity does have benefits here).

Another approach I’ve used with semi-public services is to stick them behind a proxy I trust like Caddy or nginx and gate access to them with https basic auth. Basic auth rightfully gets dismissed in many security contexts, but in the case of personal self-hosting it can serve a useful purpose. The proxy handles the basic auth, and no network packets can reach the protected application until basic auth is complete, which completely protects against unathenticated exploits in the protected application (though obviously exploits against the proxy would still work, but major proxies are pretty well hardened). The major downside here is that you can’t really use mobile apps, as none of them support this niche and frankly dubious approach to network access control. But for public sharing, you’re almost certainly having folks use a browser as their client rather than an app, and for the small convenience overhead of the basicauth login you get a pretty significant reduction in unauthenticated attack surface. The app limitation again makes this a poor match for Nextcloud, but a good match for a standalone public filesharing system that you don’t quite trust as much as your proxy.

Edit: If you want to get fancy you could even expose the same Nextcloud instance BOTH via tailscale for your own app use behind a basicauth proxy for semi-public sharing. It gets network protection in both cases, but basicauth is sort of kind of easy enough to grant semi-public access to.