Part five

Hosting and handover

What hosting actually covers, what we operate on your behalf, what a code download does not contain, where the data sits, and how PDPA responsibility splits.

§ 29 What hosting actually means

What hosting actually means

Software is not just the code. A working system is the code plus the place it runs, the database, the secrets, the domain, the certificate, the backups, the logs and the person who gets told when it breaks. When we host, we operate all of that. Nothing on that list becomes your problem.

When you take it in-house, all of it becomes somebody's job. That is fine, and sometimes it is the right answer. It is just worth knowing before you decide, because a downloaded copy of the code is not yet a running system.

Fig. 6 — What sits under a running app

Hosting is everything below the top line. Take it in-house and each of those rows becomes a job on somebody's desk.

§ 30 What we run for you

What we run for you

If you elect hosting, every item below is ours. You do not create platform accounts, you do not hold infrastructure credentials, and you do not get paged.

The application: Deployed and kept running, with the right amount of machine behind it for the traffic it actually gets.
The database: A managed Postgres database, provisioned in Asian region for client builds, with scheduled backups and point-in-time recovery.
Secrets: API keys, tokens and passwords held in the platform's encrypted store, never in the repository and never in a spreadsheet.
Domain and HTTPS: Your own domain, with the certificate issued and renewed automatically. You keep ownership of the domain itself.
Logs and monitoring: Deployment and application logs, so a report of “it broke at 3pm” can be checked against what actually happened at 3pm.
Releases: We publish changes, and we roll them back if a change turns out to be wrong. There is no release night.
Access: Private deployments where the app should not be public, and a named list of who can reach the admin side of it.
Someone accountable: The S$500 a month buys a named party who answers when it is broken. That is most of what you are paying for.

What the monthly fee covers as a matter of contract: Engagement Terms § 06 — Hosted service and support.

§ 31 Hosted, or in-house

Hosted, or in-house

Scroll the table sideways →

Concern	We host it	You host it
Where it runs	We choose and operate it	Your cloud account
Database	Managed by us	You provision and operate Postgres
Secrets	Platform secret store, rotated by us	Your key vault or secrets manager
HTTPS	Issued and renewed automatically	You or your provider manage certificates
Backups	Scheduled, and we test a restore	You set schedule, retention and restore tests
Monitoring	Logs and alerts, watched by us	You configure logs, metrics and alerting
Releases	We publish and roll back	Your pipeline, your approvals
When it breaks	You email us	Your team, or another vendor
Ongoing cost	S$500 a month, cancellable	No fee to us; infrastructure and staff time instead
Control	Less. You do not touch the plumbing	More. All of it is yours to shape

Note

Neither column is the upgrade. Hosting removes work; in-house adds control. Pick the one that matches who you have on staff on a bad Friday.

§ 32 What a download is not

What a download is not

The common misunderstanding is that owning the code and holding a running system are the same thing. They are not. A zip file has no data in it, no credentials, no domain and no backups.

Fig. 7 — A download is not a system

Everything in the right-hand box is what turns a folder of code back into a running service. It is all part of handover; none of it is inside a zip file.

What you receive

The repository, with its full history.
The database schema, the migrations and an export of the live data.
Deployment configuration: build command, start command, runtime version, ports, health check.
The list of environment variables you need to set, by name, with the values handed over separately and securely.
Uploaded files and anything held outside the database.
Written instructions: how it runs, how it deploys, how to change it.
Domain and DNS control, if it was ever pointed at us.

What you do not

Our platform accounts. You will be creating your own.
Our monitoring and alerting setup, which is ours and not portable.
Us as the accountable party. Once you run it, you run it.

The obligation itself: Engagement Terms § 08 — Ownership and handover.

§ 33 Moving it out, step by step

Moving it out, step by step

Moving off us is a small project, not a download. Here is the whole shape of it, so nobody discovers step four on a Friday afternoon.

1. Take the export: We produce a full database dump with standard Postgres tooling, plus any files stored outside it. Credentials move through a secure channel, never email.
2. Stand up the target: Your team provisions Postgres and a place for the app to run. The app is ordinary TypeScript and Postgres, so this is configuration rather than a rewrite.
3. Restore and check: Schema, data, sequences, indexes and extensions restored, then row counts and a few real business totals compared against the old system before anyone trusts it.
4. Wire the surroundings: Secrets, scheduled jobs, email sending, third-party callbacks and login redirects all point at the new address. This is where migrations usually go wrong.
5. Cut over: Lower the DNS time-to-live in advance, point the domain, watch it, and keep the old deployment warm for an agreed rollback window.

Our part

We stay available while you move, at no exit fee. There is no key we hold back and no licence to keep paying.

§ 34 Where the data sits

Where the data sits

For a client build the region is pinned before the first row is written. The database is provisioned in Asian region, and the app is deployed to a Singapore geography where the host offers one. The region is named in the Statement of Work, so it sits on the file rather than in a sales email.

Anything that touches the data is named too: the hosting provider, the database provider, the email sender, and any the app calls. If a workflow works fine without a model, we leave the model out.

§ 35 PDPA, honestly

PDPA, honestly

Hosting does not change who is responsible under the Personal Data Protection Act. It changes how much of the work of being responsible lands on your desk.

You are the organisation: You decide what personal data is collected, why, who sees it, how long it is kept and when it is deleted. That responsibility is not something a hosting choice can move.
We are the intermediary: We process what we are asked to process, to run and maintain the app. Our access is limited to the named people who maintain it, and it ends when the engagement ends.
Built in, not bolted on: Retention and deletion rules are enforced in the software. Access is role-scoped and every table is locked by default. Sensitive actions are logged.
If something goes wrong: We tell you promptly and in writing, with what we know and when we knew it. You keep the decision on whether it is notifiable and the contact with the regulator.

Plainly

Hosting with us does not make an application PDPA-compliant on its own, and no honest vendor will tell you it does. It gives you a small, named set of subprocessors, a Singapore region, controls that are actually configured, and one party to ask. Your Data Protection Officer still owns the position, and this is not legal advice.

§ 36 Which one you should pick

Which one you should pick

Let us host it when

You have no platform or DevOps team, and no plan to hire one.
You want releases in days rather than change windows.
You would rather have one accountable party than four dashboards.
The app is bounded and internal, and the value is in it working, not in owning the plumbing.

Take it in-house when

Policy requires a specific cloud account under your own procurement.
You already run a mature platform and adding one more app is nearly free.
You need network topology, private connectivity or regions we do not offer.
You want no supplier in the operating path at all.