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 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 case 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.