Connecting GH Pages to an external web app

I’m creating a project with a static site on GitHub Pages, however I also need a server-side to do the most important part of this project. After some research, I already know that the GH Pages doesn’t offer this service.
I want to use a free service at first like Heroku or Firebase and after do the migration to a paid one like DigitalOcean. Is there more recommend options to it? Also, can I connect them to the gh pages? A redirect would be fine. I want that the server link stays with
What I really want here is some recommendations and a north to the question. What is a good server service to it? Also, is possible to connect the application with the server to my static page keeping the I didn’t find so much about it in my searches.

Since GH Pages are static websites you can only leverage JavaScript to do dynamic operations, which might limit your freedom of action (compared to hosting everything on one server).

Is there a particular reason for this? (e.g. the GH domain being tied to a specific repository?)

Not just for a specific depository, but I plan to do more stuff after this and I think it would be more organized/standardized. Personally, I like the gh pages domain.
For the limitations with the Javascript dynamism I was wondering about a redirect from the gh page to a server page, but with same domain.

I’ve never come across this domain usage with GH Page — usually end users ask for the opposite, i.e. set their custom domain to point to their GH Pages website (which is indeed doable). If it’s doable, you’ll find instructions in the GH Pages Help documentation.

As for the redirection, you’d need to be able to change the settings of the domain for your specific subdomain, something which would depend on GH exposing those settings to end users (e.g. as they partly do when allowing custom domains to point to GH Pages projects).

A (rather ugly) solution would be to use frames — i.e. each page on the GH pages website being a frame that loads the actual page contents from your independent site. Although this would preserve the illusion of seeing the website under the GHP domain, it would be a rather entangled approach (every link would have to point to the GH Pages frame in order to preserve the domain).

But, if I’ve understood correctly, you’re willing to preserve the actual static HTML contents on GH Page, but rely on another website (or server) for certain dynamic services. Inserting iframes inside the static pages could be a better approach, allowing specific areas to draw from the dynamic website while preserving the main navigation and contents on GH Pages.

What about links/buttons from the server pages, the frame would stay in the gh page or change it if they are clicked? And the frames don’t have a limitation or any cons when used?
Edit: I forgot to mention the web app needs a session key to be opened.

That’s the problem, you need to ensure that all links point to GH frames which would then load the desired frame contents. An obvious limitation would be targeting specific anchors in the contents. Also, you’ll have to ensure that if someone lands on the server page the page refreshes to the GH frame (a common problems with frames, except that in this case the frame and the pages reside on different domains).

Frames are mostly a legacy feature from the HTML4 era, and the cons in their usage overweight the pros. Also, as a general rule, cross-domain operations are regarded with suspicion nowadays (and for good reasons) — e.g. cross-domain cookies trigger warnings from modern browsers — and chances are that in the nearby future new security features in browsers will either warn users about similar websites or even block them (partially or entirely).

Of course, there are legitimate use cases for similar scenarios (e.g. a single server servicing multiple websites) but this doesn’t seem the case because it’s more an attempt to smuggle a privately run website as a GitHub Pages hosted static website.

Good luck with that! — more layers of cross domain operations that have to be handled statically.

I strongly advise you to check out with GitHub staff whether this use of GH Pages website is legitimate or not. The goal of preserving to GH domain for a website which in reality is hosted elsewhere seems like an attempt to leverage GH credentials for a service which is not hosted by them — which might be seen as an attempt to impersonate GH services.

People build up expectations based on domains, and tend to trust GH Pages websites because because they are static website hosted under a trusted domain.

Mixing up GH and privately run services is unlikely to be appreciated by end users, who might (legitimately) wonder why are they being led to believe they are viewing a website on a given (and trusted) domain when, in reality, great efforts are being undertaken to masquerade the fact that the service is being run by an independent party on another machine which could be offering the entire service by itself.