Not to sound like a wet blanket, but I think you'll find it hard to make enough money to cancel out your power bill, development and admin time compared to big box names like AWS, digital ocean, etc. It could also open you up to legal problems. If someone you don't know wants to pay you (someone with no reputation they shouldn't trust with their money and data) then you probably don't want the data they are trying to host any where near your servers (use your imagination...).

That said, if you're serious or want a learning exercise look for:

• identity management/authentication - SSO or Oauth for an authentication layer. examples: Keycloak, Oauth proxy.
• resource monitoring - Metrics, monitoring, logging. some of this is just for maintaining availability of your service but you may need metrics for usage billing or cutting off access if they go over allotments. Examples: ELK stack, Prometheus, grafana, Loki, datadog
• API gateway - api rate limitingbased on identity, e.g. user Bob is only allowed to make 1000 API calls a month . Examples: 3scale.
• domain specific resource access policies - this is where it gets tricky. Depending on what application you are offering as a service, there may be access/limitation policies built in you could use or generic external options. If not, you'll need to come up with a method on your own like an authorization proxy that intercepts requests and approves or denies based on identity and usage metrics. A decent API gateway solution should allow for this customization.

I am not aware of an out of the box solutions that solve all of these problems, but there are many solutions for specific parts of this hypothetical system which is what I tried to provide with some example tech names to start your search. It's not a simple problem, but it's one basically every internet company has solved on some level.

I think there are croud-source compute reselling services you can enroll your systems in but I'm blanking on names and again you'll be lucky to break even on power.

I wouldn't try selling services that are hosted on your residential internet connection. What happens when it goes down? Is your setup redundant? Etc.

API keys are generally how this is done. You create an account system with billing and then allow account holders to generate API keys that must be included in every request. On your side you look up their account via the API key and check billing status before responding to the request.

If you don't have a lot of clients you could handle billing and key generation manually.

If there is a way to handle auth, then you can maybe put it behind a SSO platform (Keycloak, fusionauth, authlia, etc) and slap a billing system (not familiar with open source solutions here, I used to use commercial solutions like Blesta and WHMCS) to activate/deactivate user accounts. You’d need to do a lot of the expropriation and heavy lifting yourself though.

I know nothing about how it works under the hood, but it sounds like you need to let a user register only when they pay, deactivate the account when they stopped and don't let users without account to use the server.

Assuming you have more than a handful clients, you'll probably want some sort of CRM/billing system to keep track of who's paid. And then you'll want a centralized IAM tool where you can provision new accounts or deactivate ones that stop paying.

That also depends on whether the underlying service supports some sort of sso/login federation.

You can also just do everything by hand for the beginning, until it takes up too much time.

im using keycloak but that may be overkill for you.

i liked the idea behind it and also liked its implementation but it starts to become rather boring after some days or months of its use

You'd need to set up authentication and some way to take payment. The when the user pays, store data on if/when the user paid and when that expires/renews. Next, when the user authenticates, verify they've paid or have access, and go from there.