Website hosting vs app hosting (Node, Python, bots)

The word "hosting" covers two very different services. One stores files and hands them to whoever asks. The other runs your program and keeps it alive. Buying the wrong one is behind a lot of "my bot won't start" and "the control panel doesn't accept Node" messages.

Neither one wins in every case. The choice depends on what your project does when nobody is visiting.

What is website hosting?#

It is a service that stores your site's files and serves them over HTTP. MDN describes this as a static web server: it sends the hosted files to the browser exactly as they are.

This model usually comes with extras: a control panel, email on your domain, a TLS certificate and, on many plans, PHP with a MySQL database already installed. You upload files over FTP or through the panel's file browser, and the provider handles how the server runs. You usually cannot pick the runtime version or install packages yourself.

It works well for a company site, a portfolio, a WordPress blog or a landing page. See also what a static site is and where to host it.

What is app hosting?#

It is a service that runs your code in a process that stays on. You choose the language (Node.js, Python, Java, Go and others), upload the project, and the platform runs the start command and keeps it running.

MDN calls a server dynamic when it has, besides the HTTP server, an application server and usually a database: the code generates or changes the response before sending it. With app hosting, that layer is yours. A minimal example in Node.js with Express 5:

// server.mjs (or set "type": "module" in package.json to use .js)
import express from "express";

const app = express();

app.get("/", (req, res) => {
  res.send("Hello! This response was built by code, not served from a file.");
});

// The port comes from the environment; 3000 is only the local development value.
const port = process.env.PORT ?? 3000;
app.listen(port, () => console.log(`Running on port ${port}`));

The key line is app.listen: the program never exits. While it is up, the site responds. If it goes down, the site goes down. That is why app hosting comes with automatic restarts, logs and memory control.

What is the difference in practice?#

The second row decides almost everything: if something must keep running even with no visitors, it is an app.

Which projects need app hosting?#

• Bots. A Discord bot keeps a WebSocket connection open to the Gateway. Without a continuous process, it goes offline. The same applies to Telegram bots using long polling and to WhatsApp bots.
• APIs. A backend in Express, FastAPI or Spring receives requests, queries the database and responds. It needs a runtime and a port, not a folder of files. See how to host a Node.js app.
• Sites with server-side rendering. The Next.js docs list four ways to deploy: a Node.js server, a Docker container, a static export and adapters. The Node.js server and Docker support every feature; the static export is limited and does not offer what depends on a server.
• Workers and scheduled jobs. Queues, scrapers and routines that run every hour need a process of your own.
• Real-time connections. Chat, notifications and games use WebSocket, which needs a persistent process.

Which projects work well on website hosting?#

• A company site, portfolio or product page in HTML and CSS.
• A WordPress blog or store (PHP and MySQL, with one-click install).
• A front end generated as static files: React with Vite, Astro, Next.js with output: "export" and similar, as long as they do not rely on server code.

The rule of thumb: if the build output is a folder of files that works when opened in a browser, file hosting is enough. If the project needs a command like node server.mjs or python main.py to exist, it needs app hosting.

How do you know which one to pick?#

Answer in order:

1. Does the project have a start command? Yes: app hosting. No: keep going.
2. Does it need to store data that changes (users, orders, sessions)? Yes, in a language other than PHP: app hosting, with a database. Yes, with WordPress: website hosting already includes everything.
3. Do you want to choose the language version and the dependencies? Yes: app hosting.
4. Do you only need to show pages, at the lowest cost and maintenance? File hosting.

Outside these two there are VPSs and general-purpose cloud servers, where you administer the whole server. They give more freedom and more work; the comparison is in VPS vs shared hosting.

What changes when you move from one to the other?#

From website to app, you now provide what used to be invisible: the start command, the port your program listens on and the environment variables (keys, database URL). Keep secrets in variables, never in code.

From app to static site, you give up server code: forms, sign-in and APIs have to become external services or live in another app. Many teams split the two, with a static front end on one side and an API on the other, connected by HTTP calls.

How to do this on Square Cloud#

If the questions above pointed to app hosting, Square Cloud is self-service hosting of that kind: you upload the project, set the main file and the memory, and it runs in an isolated container. The container is always on, with no sleep mode and automatic restart (on by default for dashboard deploys) if the process exits with an error. That works for a Node.js or Python server as well as for a bot.

For sites, the path depends on the type. Among several runtimes, there is one for static sites (ready-made HTML, CSS and JavaScript), where nginx is always online serving your files and every update goes live right away. For servers, there are runtimes such as Node.js, TypeScript, Python and PHP. See the runtimes available today on Runtimes. Every web app gets a *.squareweb.app subdomain with HTTPS. From the Standard plan up, you can point a domain of your own by creating the DNS records shown in the dashboard at your registrar, and the domain stays registered in your name.

The squarecloud.app configuration file is optional: the dashboard generates it during deploy (runtime, memory and main file), and writing it by hand at the project root is the alternative. The plan's RAM is a pool shared across your apps, with a minimum of 512 MB per web app, and every plan includes cookieless web analytics.

The details of website hosting are on the Sites page.