Deploy model
You bring a Dockerfile or a Git repo. We build, run migrations on deploy, and attach managed PostgreSQL plus a volume for /media. ASGI works the same as WSGI — Channels and async views run without extra config.
Planned region → Canada
Not available yet. US East (New Jersey) is a region we are planning, not one you can deploy to. Hostim runs one live region today, in Falkenstein, Germany.
Hostim runs Django as a container with managed PostgreSQL and a volume for /media. The live region is in Germany, which is about 95 ms from Toronto. A US East region in New Jersey is planned and would cut that to roughly 15 ms. It does not exist yet — join the waitlist and tell us what you would move.
# docker-compose.yml
services:
web:
image: my-django-app
environment:
- DJANGO_SETTINGS_MODULE=config.settings.prod
db:
image: postgres:16
volumes:
- db_data:/var/lib/postgresql/dataCanadian Django shops tend to be small teams doing serious work: healthcare tools, municipal services, internal platforms for organisations that ask hard procurement questions. That shapes the decision differently than it does south of the border. Cost matters, but the first question in the room is usually where the data lives and who can be compelled to hand it over. Our answer for a US East region has to be precise: the servers would be in New Jersey, the operator would still be HOSTIM.DEV UG in Germany, and neither of those is "in Canada". For a private-sector app under PIPEDA that is normally workable with the right contract. For Nova Scotia public-sector work under PIIDPA it is not, and for BC public bodies it depends on their own policy since the statutory rule was dropped in 2021. On the technical side there is less to argue about — Gunicorn or Uvicorn in a container, migrations on deploy, managed PostgreSQL, /media on a persistent volume, flat monthly pricing.
Expected latency. The expected site is Secaucus, New Jersey; the exact facility is not fixed and any northern New Jersey site gives similar figures. The figures below are typical round-trip times for that metro — they are estimates for the location, not measurements from Hostim hardware, because there is none there yet.
| City | Expected RTT to US East |
|---|---|
| Montreal | ~12 ms |
| Toronto | ~15 ms |
| Ottawa | ~16 ms |
| Halifax | ~25 ms |
| Winnipeg | ~40 ms |
| Calgary | ~55 ms |
| Vancouver | ~70 ms |
Privacy law. PIPEDA at the federal level, Quebec Law 25 (the strictest of the set, with transfer assessments and breach reporting), and Nova Scotia's PIIDPA, which still requires public-sector data to be stored and accessed only in Canada. British Columbia dropped its blanket residency rule in November 2021, so BC public bodies now decide foreign storage by their own policy rather than by statute.
Who enforces it. the Office of the Privacy Commissioner of Canada (OPC), and the Commission d'accès à l'information for Quebec.
Data residency — read this before you plan a migration. US East is in New Jersey, not Canada. If your contract or your provincial rules require Canadian storage, this region will not meet that requirement — tell us on the waitlist form and we will count it as demand for a separate Canadian region rather than pretending US East solves it.
Market context. Toronto and Montreal are 12–15 ms from New Jersey, so a US East region serves most Canadian users well. The exception is public-sector and health work: Nova Scotia requires storage inside Canada by statute, parts of the Quebec public sector do too, and many BC public bodies still require it by internal policy even though the statutory rule was removed in 2021. A New Jersey region does not satisfy any of those. Private-sector SaaS under PIPEDA generally can use a US region with the right contract terms.
What you are probably comparing us against: Heroku, Render, Railway, DigitalOcean, OVHcloud Canada, Vultr Toronto.
Modern Django deployment is container-based. The app runs under Gunicorn or Uvicorn, with PostgreSQL on a separate service and persistent storage for media uploads. Hostim mirrors this layout one to one.
You bring a Dockerfile or a Git repo. We build, run migrations on deploy, and attach managed PostgreSQL plus a volume for /media. ASGI works the same as WSGI — Channels and async views run without extra config.
Two common failure points: media files lost on container restart, and DATABASE_URL hardcoded for local dev. Hostim provides persistent volumes for /media and injects DATABASE_URL at runtime.
DJANGO_SETTINGS_MODULE, SECRET_KEY, DEBUG, ALLOWED_HOSTS, DATABASE_URL
No. It is planned. The waitlist decides how seriously we take it and how much capacity we build. Today the only live region is Falkenstein, Germany.
No. US East means New Jersey. If your requirement is storage inside Canada, US East does not meet it, and you should say so on the waitlist form so we count it as demand for a Canadian region instead.
No. HOSTIM.DEV UG is registered in Germany. A US region would mean US-located hardware operated by a German company — which is an unusual combination and worth checking against any contract clause you have about foreign processors.
Around 15 ms to the planned New Jersey site, compared with roughly 95 ms to Germany today. For a server-rendered Django app that difference is visible on every page load.
There is no date, because the build has not been decided. We review the waitlist eight weeks after this page goes live and decide then. Everyone on the list gets an email either way — a date if we build, a plain no if we do not.
We are deciding how much capacity to build. Add your name and what you would run — that is the whole input. You can also deploy to our live German region today if that works for you.
Platform figures from the published price list, docs and our own benchmark.
€2.50/month
Hostim entry app plan
Plan sa-1-1: 1 vCPU, 1 GB RAM. Flat price, billed hourly, no usage meter.
€0
Managed database free tier
PostgreSQL 256 MB, MySQL 256 MB, Redis 128 MB, volume 1 GB. No cap on how many free instances you create.
Included on every plan
Database high availability
PostgreSQL and MySQL run as a primary plus hot standby with automatic failover, shared plans included.
2,708 TPS
Managed PostgreSQL write throughput
pgbench, 4 clients, 300 s, plan drp-50 (2 vCPU / 4 GB). AWS RDS db.t4g.medium scored 1,080 TPS on the same test.
€0/GB
Traffic charges
No ingress fees and no per-GB egress line on app plans.
1 today (Falkenstein, Germany)
Regions
Bare metal, EU only, with more regions planned. No AWS, GCP or Azure underneath.
“Managed PostgreSQL runs as a replicated cluster with automatic failover on every plan, shared and dedicated alike.”
— Hostim.dev docs, managed PostgreSQL