Skip to main content

Schrems II

Schrems II Laravel Hosting

Schrems II made transferring personal data to US-based platforms a serious legal exercise: SCCs, Transfer Impact Assessment, supplementary measures. The simplest answer is to not transfer at all. Hostim runs your Laravel Docker container in Falkenstein under a German operator — no transfer, no SCCs, no TIA.

Try Laravel on HostimAll Laravel docs
# docker-compose.yml
services:
  web:
    image: my-laravel-app
    environment:
      - APP_ENV=production
      - DB_CONNECTION=mysql
  db:
    image: mysql:8
  • 🇪🇺 Hosted in Germany, GDPR by default
  • 🐳 Run Docker apps (Compose supported)
  • 🗄️ Built-in MySQL, Postgres, Redis & volumes
  • 🔐 HTTPS, metrics, and isolation per project
  • 💳 Per-project cost tracking · from €2.5/month

What Schrems II means for Laravel

A Laravel app on Forge + DigitalOcean, on AWS Lightsail, or on a US PaaS is a transfer of personal data to a US operator from the EU controller's perspective. The Schrems II decision invalidated the Privacy Shield and put strict limits on this even with SCCs. Hostim removes the transfer entirely: HOSTIM.DEV UG in Germany, all data in Falkenstein, no US sub-processor for application data. Your queue worker, your MySQL, your storage volume — all inside the EU.

What this means in practice

Definition. The Schrems II decision invalidated the EU-US Privacy Shield in 2020 and put strict limits on transferring personal data to US-based providers. Even with Standard Contractual Clauses, controllers must run a Transfer Impact Assessment and add supplementary measures if the third country does not offer EU-equivalent protection.

Why an EU host matters. The simplest answer to Schrems II is to not transfer data outside the EU at all. An EU-hosted, EU-operated platform removes the transfer entirely — no SCCs, no TIA, no supplementary measures.

What Hostim provides. EU-only hosting under an EU legal entity. No sub-processors outside the EU for application data. The platform is operated from Germany; engineering and support are EU-based.

What Hostim does not claim. We use a payment processor (Stripe) which has its own sub-processor chain — that is standard for EU SaaS but worth noting in your privacy policy.

How Hostim runs Laravel

Laravel hosting was traditionally shared LAMP with FTP uploads. Modern Laravel deploys are container-based: PHP-FPM plus Nginx in one image, MySQL or PostgreSQL on a separate service, and a queue worker as a second container. Hostim runs this layout natively.

Deploy model

Push your Dockerfile. We run php artisan migrate on deploy, attach managed MySQL, and start a separate queue worker container that shares the same image. Storage is on a persistent volume — uploads survive deploys.

Common pitfalls

Two things often break: queue workers running as the same container as the web server (they should be separate), and the storage symlink not surviving a rebuild. Hostim solves both with explicit worker apps and persistent volumes.

Typical env vars

APP_KEY, APP_ENV, DB_CONNECTION, DB_HOST, QUEUE_CONNECTION

FAQ

Do I need SCCs to use Hostim?

No. Both Hostim and your data are in the EU. There is no transfer to a third country, so SCCs do not apply.

What about Stripe for payments?

Stripe processes payment data under its own contracts. For application data (your users, your database, your storage), there is no US sub-processor.

Can I use this for German public sector clients?

For most commercial public sector cases, yes. For projects that explicitly require BSI C5 or TISAX certification, we cannot serve as sub-processor today.

How does Laravel queue work?

Run a separate worker app in the same project (php artisan queue:work). It shares Redis and MySQL through env vars. The queue itself stays in the EU.

Related pages

Ready to deploy Laravel?

Spin up an app in minutes. Managed database on the free tier, custom domain included.

Deploy your Laravel appSee pricing