Lets say you have the full stack app written out in code, and it works locally. Now you need to deploy your code somewhere.
Where and how you do that is essentially an operations task. If you were a traditional business with IT, this usually is handled by other non-developers, who manage the infrastructure of your company, such as physical servers, computers, or possibly even virtual ones within the cloud.
If you’re working alone on a given project, this means you must do this yourself. You have a number of options out there on how you want/need to run your project. Most often you’ll want to use an online service you deploy your code to that runs it at some level. This usually means you ignore the option of having the code run literally in a computer in your closet. As this means you open up your local network to the wider web, which introduces complexity and risk.
The online services available to run your code ranges. I’ll go over a few broad options from the “lowest” level where you have the most control, but the least “help” from your provider to the “highest” level where you have the least control, but the most “help”.
Usually the lowest option is a VPS, or Virtual Private Server, or more generally IaaS, or Infrastructure as a Service. This is essentially that “computer in your closet” except as an online service somewhere. A specific example would be Digital Ocean. This is where you pay for a machine somewhere on the cloud that you can SSH into, and “do stuff” in it how you please. Digital Ocean will keep the machine running, and connected to the internet, and maybe a few housekeeping things like warning you about OS updates, but you will have to set everything else up, including your software stack. This is the most flexible, but most hands on option.
A middle option is usually some form of PaaS or Platform as a Service. An example would be Heroku’s Dynos. A PaaS usually means a service that takes your code and runs it in a specific environment provided and specified by the provider. So in this case you can take your nodejs back-end and configure it as specified by your provider and Heroku will handle the details. This is usually much more hands-off as the provider will handle most aspects of running your app, except you lose out on a lot of flexibility and options. However this usually saves you time, especially if you mainly care about programming rather than fiddling with systems.
The final option is usually called FaaS or Function as a service. An example would be Firebase’s Cloud function. This is where you write functions in a given programming language for a specific platform, and it takes that the code you wrotedirectly and runs that. You have very limited flexibility with this setup, but now you don’t even have to write a full “back-end stack”. This route usually is taken for speed, and simplicity, where you lean on your service to the fullest. This could allow you to do things faster/easier, but you will eventually run into some platform limitations you might have to work around. For example, you usually can write your functions with only specific language versions. Or you can’t manage how/when/if the functions runs a certain way, like for how long. You also can only manage logic at a function-level, and can’t do things globally, or at other levels of your code.
note The three primary cloud providers, AWS, Azure, and GCP all support each of the three offerings and then some, with some merging different aspects with different capabilities. I provided other options that are more approachable, and sometimes more affordable (Heroku and Firebase have free options)
update I also forgot to mention there are other types of services that I didn’t mention here. Like a JAMStack provider, or static hosting.
You usually want to start with a PaaS (the middle option) and use something like Heroku (which has a free tier!) as its the easiest and cheapest to get started with.
I might of focused on the “types” of infrastructure you’d consider, but I still glossed over other topics like “how to handle deployment itself”, as it can vary. I also skipped over a lot of other topics like how to actually “bundle up” your code, or monitor it after you deploy it, or fixing issues with your deployment itself. All of these are dependent on which route you take, and other details like how your handling deployments.
You can go into all of this “ops” stuff in depth, or just keep it simple. Regardless, it can be interesting and fun, but still more to learn.
Good luck, keep learning, keep building!