Your app needs a real runtime, not a folder on someone else’s server.

There is a point where a website stops being a collection of pages and becomes a running system. A form writes to a database. A background job sends the receipt. A login sets a session. A webhook arrives while nobody is looking. At that point, the hosting question is no longer “where do the files live?” It is “where does the process live, and what happens when it restarts?”

That distinction is easy to miss because the first version of almost everything fits in a shared hosting plan. Upload the files, create a database in the control panel, and it works. The trouble starts when the application needs something the file-based model cannot provide.

What a runtime actually gives you

A runtime is the environment your code expects: a specific language version, extensions, environment variables, a start command and a process that stays alive. It is also the thing that lets you say “this release runs the same way on my laptop and in production” without shipping your laptop.

On Shika Deploy, an app is a container built from your repository or a Dockerfile. The build installs dependencies and produces an image. The runtime starts a process, attaches a port, and puts the proxy in front of it. The database and certificate are wired before the first request.

If the build is not repeatable, the deploy is not repeatable. Everything after that is guesswork.

Three signs you have outgrown file hosting

1. You need a worker. Sending email, processing images, generating reports or syncing an integration should not happen inside a web request. A container can run a queue worker beside the web process.
2. You need a real database connection. Connection limits, storage engines and backup behaviour matter once the app is writing data continuously.
3. You need a repeatable build. “It worked when I uploaded it” is not a deployment strategy. A lockfile, a build command and a start command are.

The part people underestimate: restarts

A process will restart. A node will reboot. A release will replace a container. The question is whether the app comes back with the same environment, the same storage and the same database connection. Persistent state belongs in a database or a mounted data directory, not in the container’s writable layer.

# state that survives a redeploy
/data/uploads
/data/cache

# state that disappears with the container
/tmp
/var/www/html/storage

Once that boundary is clear, moving between a VPS and a managed platform becomes much less scary. The application owns its code, its schema and its data contract. The platform owns the runtime, the proxy, the certificate and the restart.

That is the standard we build toward. Not “it runs on our machine”, but “it comes back on its own, with the same inputs, and tells you when it did not.”