Over the past 15 years, we built Clever Cloud to avoid that trade-off, to offer a versatile European platform with managed services, on infrastructure we control, from partners or yours. Where your application always runs the way you designed it.

A complete platform, not a compute layer

What sets Clever Cloud apart is not any single feature — it is the breadth of what runs natively on the platform, managed by our team, on our infrastructure.

Deploy applications in 18 runtimes: Node.js, Bun, Python (with uv), Java (Gradle, Maven, WAR), PHP, FrankenPHP, Ruby, Go, Rust, .NET, Elixir, Scala, Haskell, V, Meteor.js, Docker, and two static runtimes — one based on Static Web Server/Caddy with automatic SSG detection (Hugo, Astro, Docusaurus, Zola, VitePress, Nuxt, MkDocs, mdBook, Storybook), the other on Apache with .htaccess support for SPAs and rewrite rules. If none of these fit, push a Dockerfile — full filesystem, TCP/UDP ports, multiple processes, your rules.

But compute is only the beginning. The platform includes managed PostgreSQL (versions 14–18, 40+ extensions, replicas, Pgpool-II), MySQL, MongoDB, Redis, Elastic Stack, and Materia KV — a serverless key-value store built on FoundationDB, replicated across three datacenters, with a Redis-compatible API. S3-compatible object storage with Cellar. Persistent filesystem with FS Buckets. Distributed pub/sub messaging with Apache Pulsar. An API gateway with Otoroshi. Identity management with Keycloak. Business intelligence with Metabase. Privacy-respecting analytics with Matomo. Git hosting with Heptapod. Transactional email with Mailpace. Easy ways to deploy preview applications from GitLab or GitHub.

Every database can be encrypted at rest with LUKS2/AES-XTS. Every service is provisioned as a managed add-on — one click, environment variables injected, integrated with your applications.

Co-built with open-source partners, integrated as managed services

Several of these services — Otoroshi, Keycloak, Metabase — are not just products we bundle. We co-build them with their respective communities, contribute, and operate them as fully managed offerings on our infrastructure. When we add a feature to Otoroshi or work on Keycloak's deployment model, that work benefits the open-source project and every Clever Cloud customer.

This approach extends beyond software. We are building an ecosystem of partners — resellers, system integrators, and technology partners — who bring domain expertise on top of the platform. Our academy trains teams to operate confidently on Clever Cloud, from onboarding to production. The goal is not to lock anyone in, but to create a network of people and organisations who know how to build well on European infrastructure.

Request flow: a programmable middleware chain

HTTP traffic on Clever Cloud does not go straight from the internet to your application. It passes through our Rust-based load balancer Sōzu and you can configure a chain of middleware — the Request Flow — that you control with a single environment variable.

Set CC_REQUEST_FLOW to compose a pipeline from built-in services: Varnish for HTTP caching, Redirection.io for URL rewrites and SEO-friendly redirects, OAuth2-Proxy for authentication, Otoroshi Challenge for request verification. Or plug in your own reverse proxy with CC_REQUEST_FLOW_CUSTOM, the platform handles port allocation automatically.

Need to cut public HTTP access entirely while keeping private networking alive? Set the flow to block. The platform returns a 200 OK to health checks while refusing all other traffic. Your application stays reachable through Network Groups, but invisible from the internet.

This is not a feature you find on most PaaS. Typically, you either get a fixed reverse proxy you cannot configure, or you set up your own Nginx/Caddy/HAProxy and manage it alongside your application. On Clever Cloud, the middleware layer is a first-class platform service.

Mise: one config file for tools, tasks, and environments

Every Clever Cloud runtime comes with Mise and can automatically add tools before the build phase. Drop a mise.toml at the root of your project, and Mise handles tool versions, environment variables, and build/run tasks declaratively.

This means you can install Deno on a Node.js runtime, get Bazel to build your project, pin a specific Hugo version on a Static runtime, or define build commands that work identically on your laptop and in production — without writing shell scripts or customising buildpacks. On the Linux runtime, Mise tasks are first-class: the platform checks for CC_BUILD_COMMAND/CC_RUN_COMMAND first, then Mise tasks, then Makefile targets.

Private networking with WireGuard and Tailscale

Network Groups create encrypted WireGuard overlay networks between your applications, add-ons, and external peers. Each member gets internal DNS resolution (<memberID>.m.<ngID>.cc-ng.cloud), all ports are accessible within the private network, and traffic never touches the public internet. Build microservice topologies where services communicate privately and only the API gateway faces the public.

For teams already using Tailscale, the integration is native: set TAILSCALE_AUTH_KEY and each application instance joins your Tailscale network as CC-<NAME>-<INSTANCE_NUMBER>. Use TAILSCALE_LOGIN_SERVER to point at a self-hosted Headscale control server. Accept DNS settings, advertise routes — it works the way you expect.

We also support IPSec and OpenVPN for environments that require them. Dedicated outgoing IP addresses are available for firewall whitelisting.

API first, AI ready

Clever Cloud is exposed as an API, built with Infrastructure-as-Code in minde. We built our own integrations on top of it. From the web Console to Terraform provider and major tools such as Kubernetes Operator, the Clever Tools CLI and its amazing AI Skills.

To ease AI usage, we provide LLMs.txt documentation summary, all pages are provided in Markdown format when requested by your favorite tools. Want to explore a deployed application ? clever ssh gives you a shell on your production instances, but you can also use clever ssh --command 'any command' and directly get the results. A great feature when you need Claude Code, Codex, Gemini or OpenCode to debug a running application.

Observability: Grafana, Warp 10, and custom metrics built in

Every service comes with a Grafana dashboard. CPU, RAM, disk, network, and requests per second are collected automatically. Pre-configured dashboards live in a "Clever Cloud" directory, and you can create your own, including alerts that notify you when consumption crosses a threshold.

Under the hood, metrics are stored in Warp 10, a geospatial time-series database with microsecond precision you can query with WarpScript — a stack-based language.

For custom instrumentation, push to StatsD on port 8125 or expose a Prometheus endpoint on localhost:9100. The platform collects over 170 Telegraf metric classes, all labelled with owner_id, app_id, host, and deployment_id. Blackfire profiling and New Relic integration are available for deeper application-level analysis.

Most platforms charge extra for observability, limit retention to hours or days, or require you to set up external tooling from day one. On Clever Cloud, logs are retained for 7 days with regex search, access logs come in multiple formats (CLF, JSON with geolocation and TLS version), and log drains forward to Syslog, Elasticsearch, Datadog, or New Relic without per-gigabyte surcharges.

Otoroshi: API gateway, WAF, and LLM gateway in one

Otoroshi is not just a reverse proxy. It is a managed API gateway that includes a Coraza WAF running OWASP Core Rule Set in WebAssembly — detection or prevention mode, custom rules per domain, audit logs for compliance. No "Enterprise tier required" caveat.

The LLM extension turns Otoroshi into a unified gateway for large language models, exposing an OpenAI-compatible API that routes multiple providers: OpenAI, Anthropic, Mistral, Cloud Temple, DeepSeek, Gemini, Groq, HuggingFace, Ollama, OVHcloud, Scaleway and others. Semantic caching reduces redundant calls. Quota management controls costs. Automatic failover switches providers transparently when one is down. Prompt fencing prevents sensitive information leakage. MCP (Model Context Protocol) support lets you build tool-using agents.

This runs as a managed service on your Clever Cloud account — no separate vendor, no per-token markup. It's the tool we chose to build the technology at the core of Clever AI.

Clever Tasks: run, pay, stop

Not every workload is a web server. Clever Tasks are applications that execute a command and shut down. Define any application as a Task, set CC_RUN_COMMAND="python manage.py migrate", trigger with git push or clever restart, and the scaler runs for exactly as long as the command takes. You pay for build and execution time, per second.

Use them for database migrations, test suites, file conversions, data processing, compilation jobs — anything that should not run on an always-on instance. Chain multiple commands with && or wrap them in a script. Every environment variable from your application is available.

This is fundamentally different from cron-based schedulers with 10-minute minimum intervals, 5-task limits, and "execution is expected but not guaranteed" disclaimers. A Clever Task runs when you tell it to, for as long as it needs to, and stops when it is done.

European infrastructure, real sovereignty

Clever Cloud runs on infrastructure we operate across many regions: Paris, Gravelines, Roubaix, London, Warsaw, Montreal, Singapore, and Sydney. We partner with European providers — OVHCloud, Scaleway — and do not depend on a single US hyperscaler. Our approach to sovereignty is structural: 100% French capital, European-only hosting, no exposure to extra-territorial legislation.

Several regions carry HDS certification (Hebergement de Données de Santé), the French regulatory standard for hosting health data. This applies to all managed databases in those regions — PostgreSQL, MySQL, MongoDB, Redis, Elastic Stack — not just a subset. It is not an add-on with a monthly surcharge; it is built into the infrastructure. For organisations requiring the highest level of qualification, we also offer SecNumCloud-grade options within our cloud offer.

Data stays in the region you choose. There is no "default to us-east-1" behaviour, no background replication to a jurisdiction you did not select, no fine print about processing data in another country for operational purposes.

Predictable pricing

Billing is per second, based on instance size and runtime duration. Not per invocation. Not per request. Not per edge cache hit. Not per million operations on a key-value store. Your monthly bill varies by roughly ±5%, because it tracks actual compute usage — not traffic spikes multiplied by unit rates you did not notice in the pricing page.

Log drains do not cost per gigabyte. Grafana dashboards and Warp 10 metrics are included. Databases backups are included. Observability is included. You do not need to budget for six line items just to see how your application is performing.

What we are building next

We know where the platform needs to grow and listen to market needs Clever Kubernetes Engine is our current development priority. But we also work on many new features and services. Feel free to tell us what you expect the most.

Welcome to the first edition of One Framework a Day keeps the Boredom Away. In this series I will show you how to deploy a particular framework on Clever Cloud.

This post 0 is a little different as its goal is to explain you how Clever Cloud works and to help you get setup. If you already know Clever Cloud and have the CLI installed, wait for the next post tomorrow :)

What is Clever Cloud?

Clever Cloud is a Platform as a Service. We like to say we provide IT Automation and Application Sustainability. That and additional sleeping hours and serenity for our users.

IT Automation

What we mean by IT Automation is that we automate things. Beyond this obvious statement, what is important is that we do it, so you don't have to. You should be able to focus on writing code because it is what brings value to your organization. Anything else than code is infrastructure. It's a cost. We'll manage it.

To make it work you just have to agree with a couple of loose rules (well, 12 actually) and everything will be fine. If you use a build tool, just add a json file telling us which build tool goal we have to run, push your code and we do the rest.

From now on your application is up and running on Clever Cloud. That's where Application Sustainability kicks in.

Application Sustainability

What we mean by Application Sustainability is making sure your application stays in production. To do so we provide hardware monitoring out of the box. Even better, since you are usually using a build tool we know what runtime you are using so we know how to monitor it. We automatically integrate with Java's JMX or Haskell's EKG for instance.

This monitoring allow* us to give you additional features like self-healing: If your application crashes or does not answer we restart it automatically. We also bring automatic scalability both vertically and horizontally. And everything happens without downtime because we do blue/green deployment. Meaning, when we need to update a VM (say for an OS update or a security fix), we don't update it per se. We restart the same cycle on a brand new, updated VM. Once it's up, our reverse proxy simply redirects traffic to the new one(s). In that way, we decorelate service uptime from server uptime.

We can do all that because we embraced Immutable Infrastructure. This concept appeared somewhere around 2010 and is a full paradigm shift. Basically, not a single part of your infrastructure will ever be updated in place. It will either be created or removed, never modified. Modifying something creates uncertainty and possibly an inability to be reproduced. Immutable Infrastructure ensures reproducibility.

Applications or add-ons?

To support this, we manage two different concepts: Application and Add-on. Applications are stateless. They are represented by a runtime and sometimes a build tool. For example a Wordpress website does not need a build tool, just a runtime: a web server. As developers, application is where we spend the most time on. This is where we create value. All applications instances (VMs) are immutable. So you need to make sure your deployments are stateless. You have to store state in a database, object store or filesystem.

Which is where add-ons come in handy. They are not yet managed as Immutable Infrastructure (it is however part of our plan). They all our DBaaS (which all have automatic and on-demand backups), our shared filesystem, object storage like S3 etc… It also includes stuff like Jenkins, Artifactory, GitHub Enteprise, Gitlab and more.

Hopefuly this gave you a much better idea of what is Clever Cloud. We could go on longer but I will assume you are bored already. So moving on to practical things :D

Deploy your first Application

To create an account, simply go to our website and click on 'Sign UP and Try'. If you do not have a GitHub account you can signup manually here. Once you have an account you can start playing around with your free credits. Take a look at some of the videos we made on our YouTube channel.

Setup the CLI

After you have setup your accout you can install our CLI. It will be heavily used on most posts of the One Framework a Day series. There are a couple of ways you can install it. First you can checkout the GitHub project and build it from source. It's Node.js app so you will need npm, node and a couple of other dependencies described in the Readme.

You can also use a package manager or installer. Head over to our documentation to get the details for MacOS and homebrew, Windows and chocolatey or Linux and its prebuilt binaries.

Test the CLI

If you have an account and installed the CLI, you should be able to test your first application. First thing to do is to link your account to the CLI. Simply type clever login. This will get you through a login prompt to retrieve your newly created identification tokens.

Create a new directory called hello-world-app and inside create an index.html file containing the string Hello World. Then initiate a new git repository and commit the html file. Here are the steps you need to follow if you have a Unix system:

mkdir hello-world-app
cd hello-world-app
touch index.html
echo 'Hello World' > index.html
git init
git add index.html
git commit -m "my new website"

You now have a static website ready to be deployed to Clever Cloud. First you need to create an application of type static, then deploy the content of your site to the newly created application. Once it's done, open the website in your default browser:

clever create --type static-apache hello
clever deploy
clever open

Conclusion

Now you should know more about Clever Cloud and you have deployed your first application. Please note that if you don't like command line, you can also do all of this from our web console or our API. Actually, both the CLI and the console use our API :) This also means you can script whatever you want! And now remember that all the next posts will be dedicated to deploying a particular framework on Clever Cloud. See you soon :)

We use logs for everything, to track errors, measure performance, keep a journal of how our software runs, or even debug code in production. Since we use it so much, we should be good at it by now, right?

Surprisingly, well written, useful logs are not frequent. The norm is logs full of garbage, old debug statements ("I was here"), unhandled exceptions, and non actionable information.

You read the file, looking for that one word, that should be followed by another word, but two threads are performing the same task and each will output the two log messages. Maybe, if you look at the timing, you'll know which is which.

You try to make sense of multiple interleaving messages, but they come from two machines with desynchronized clocks, and one of them is sending batches of messages every second instead of sending them as they are generated. You wonder if the code is executing in the right order and write essays about causality and determinism.

I have a hundred stories like those, and there's a common theme, a root cause for the way we write logs. As a developer, we think of them first as a developer's tool, not as the main interface to check your app's health in production. They are meant to be read with tail while the application runs on small workloads, for a limited time.

Developer logs VS ops logs

Managing software in production means detecting when something is wrong, but knowing every bit of the program's state is a counterproductive way of doing it.

You want to know the important metrics:

• someone consulted a web page: leave that to your web analytics software
• someone consulted a web page, but the app failed to answer: log it
• someone consulted a web page, and the page's size is larger than the buffer: don't log it, it's useless most of the time
• someone bought something: log it, even if you have a backend to see that
• someone bought something and the server failed: log it and send an email to the dev team to fix it right now

More generally, here is a scale from ops log to developer log:

• a transaction has been performed, successfully or not => ops logs
• individual steps of that transaction failed => ops logs
• individual steps of that transaction succeeded => dev logs
• value of variable X at point Y in code => definitely developer logs

Here is an example (from code I wrote) of developer centric logs:

I am not saying developer info should not appear in logs. Just that it is best hidden under "debug" or "trace" levels, if your logging system supports levels (most do). It is fine to have useless messages in there, as long as they are not used in production/ It is fine to use "printf debugging" in development, but it should never appear in production.

Your goal in writing logs is to spare time for the person that will read them. It may be a sysadmin in your company, a client using your software, or yourself, six months from now, trying to put the app back online at 2 AM. Please think of your future self.

Making the logs more ops friendly

To make the life of the journal's reader easier, you need to optimize for two reading engines:

• filtering software, like grep
• the human eye

Why the human eye?

Because we are good at detecting patterns, and filtering out the useless parts of an image. If a sequence of three lines appears regularly, we will see it easily. If we only care about the message part of the log, not the prefix (time, PID, etc), we will focus our attention on it and ignore the rest.

The consequence is that everything that will break the brain's flow will make your logs harder to read. if the user id appears at the beginning of one message, but at the end of another one, it will be much harder to see which messages are related.

Fortunately, what works well for the human eye also works for filtering tools. Standardized, common prefixes are easy to search for, and easy to recognize. Related information should have identifying information, always stored in the same place.

Practical advice

How can you apply those principles right now? You begin by making a small wrapper over your logging library to automatically insert useful information, in a fixed format:

• a timestamp, preferably in ISO8601 (easier to read) at UTC (no timezone conversion when reading). By the way, make sure your servers are all set up to use the same timezone, this will save headaches
• a timestamp from a monotonic clock if your application is time critical
• identify the current instance: add a server identifier (name, IP, whatever) and an instance identifier (process id, thread id)
• the running code's version (commit id or version number)
• the file's name, line number, class and function names are useful for debugging, so add them for the "debug" and "trace" levels (but don't activate those levels in production unless you have a good reason)
• add some correlation information: the user id, a request id, anything that will let you track which action resulted in which messages
• code status: are we in the middle of an error? Is something pending?
• then, at the end, you can put a written message. You can use structured logging instead of raw text if you want to track data with more automated tools

This is a lot of information to put on one line, but we have great tools at our disposal. We can filter on one of these fields and remove it from the output. We can use terminals larger than 80 characters. We can even color parts of those logs to let the eye separate them easily.

If I had to rewrite the previous example logs that way:

Side note: beware exceptions. It is fine to display an exception's stack trace while debugging the code, but an exception in production means two things:

• you forgot to replace the stacktrace with a proper error message for an exception you handled
• there's an exception that you do not handle in your code

In both cases, it is a signal that something wrong happened and that it should be fixed soon. Also, it usually messes up the log's format, and fills up the log with useless information. I once heard about an app that needed to run on machines with big disks and big CPUs, because there were so many exceptions logged that the machine could not keep up.

Anyway, The goal of that approach is to have a common format for every message, simple to parse and filter. Make sure that those common parts have the same length, and that you use the same separators everywhere. Tabs are usually better than spaces, since we rarely use them in log messages. This will make the logs easier to read, and much easier to filter for.

With a good logging discipline, you will soon see non conforming messages as bugs, and you will be much more efficient when debugging and operating your application.

• unclear risk and impact on the business
• time spent tracking new vulnerabilities for various applications
• unclear result of updating code (will it stop working? Will it break other applications on the same machine?)

Defining your risk budget

• targets: user data, intellectual property, machines
• entry points: web server, internal WiFi
• weaknesses: unpatched application, SQL injection, key employees victims of phishing

Staying up to date with security news

• avoid news websites. They write long articles, they want you to panic and they rarely provide usable solutions
• Follow security mailing lists. There are generalist ones, like oss-security@lists.openwall.com and cve-assign@mitre.org. There are more specific ones, like debian-security@lists.debian.org (translate to your specific distribution), or rubyonrails-security@googlegroups.com and ruby-security-ann@googlegroups.com. There is also fulldisclosure@seclists.org, where 0-day vulnerabilities are sometimes published
• Twitter is still a good source of information on vulnerabilities, since people easily share. If you see security people suddenly buzzing in your timeline, you should pay attention. There are good lists of people to follow to get you started here and there. They each have their own focus, though, so you may not be interested in everything
• keep up with new versions of your software and their dependencies. Use your package manager, project specific mailing lists, subscribe to their github feed

• check the mailing lists, see if you use any of the applications mentioned
• check your dependencies: anything new? Any security issues mentioned?
• check Twitter: is the world on fire?

Reducing the risk of code updates

• staging environments to test updates
• replacing huge, risky updates with small increments
• applications can be completely independent. Updating the company's WordPress blog will not affect the SaaS application

• get notified of a vulnerability
• see if it applies
• see if there's a patch (or if you can develop one quickly)
• apply the patch
• redeploy the applications
• go make yourself a nice tea

• The recent CVE-2016-0728 is a privilege escalation in Linux, something we need to take seriously. We took a look at the advisory, wrote a patch, tested it and deployed it in a few hours. Most Linux distributions took days to publish updated packages.
• In the same way, the infamous Heartbleed bug was fixed quickly. One of our clients came to us hours later asking if we knew about it: "oh, that's the reason my applications were redeployed in the middle of the night"

Devs are just like other workers. They waste a lot of time with non-productive (and often boring) tasks.

A recently published article from ICT Journal (original report done by Zero Turnaround "Developer Productivity Report 2012") said that developers dedicate only 1/3 of their time to writing code. It represents only an average of 15 hours per week.

As you can see on the graph above, "Overhead tasks" like deployment take 4 hours per week.

Clever Cloud can improve these time consuming tasks and give developers much more time to do what they like (amongst others): working on the codebase.

For example, you can check out the video tutorial we made for deploying a Play! application:

Pretty fast right?

Now just imagine how much time can be saved with this solution.

Using a PaaS (Platform as a Service, for instance Clever Cloud) also allows you to save much time by not doing maintenance on an infrastructure (either your own or an IaaS – Infrastucture as a Service).

You haven't tried Clever Cloud? Do it for free.

Version française

Les développeurs sont comme les autres travailleurs. Ils perdent un temps fou avec des tâches non productives (et souvent ennuyeuses).

Une étude récement publiée de ICT Journal (« Developer Productivity Report 2012 », Zero Turnaround, 1 800 développeurs, principalement Java, sondés en ligne) annonce que les développeurs ne passent que 33% de leur temps à coder. Cela représente environ 15 heures par semaine.

Comme vous pouvez le voir sur le graphique plus haut, les "tâches annexes" représentent 4 heures de travail hebdomadaire.

Clever Cloud peut améliorer le temps perdu avec ces tâches et donner aux développeurs plus temps pour faire ce qu'ils aiment (entre autres) : travailler sur le produit.

Vous pouvez par exemple jeter un œil sur le tutorial vidéo du déploiement d'une application Play! :

Rapide, non ?

Maintenant, imaginez combien de temps il est possible de gagner avec cette solution.

Utiliser un PaaS (Platform as a Service – exactement ce que fait Clever Cloud) permet aussi d'économiser beaucoup de temps normalement alloué à la maintenance lorsque vous possédez votre propre infrastrucuture (ou un IaaS – Infrastucture as a Service).

Vous n'avez pas encore essayé Clever Cloud ? Faites le gratuitement.

Until last week, it was not possible to use a credit card to pay on Clever Cloud. But now, it is!

Our new payment method works with MasterCard and Visa. Currently we only accept Euros. Dollars will come soon.

Our CB payment method is powered by Paymill.

For more informations, do not hesitate to contact us.

French version

Jusqu'à la semaine dernière, il n'était pas possible d'utiliser une carte de crédit pour payer sur Clever Cloud. Maintenant si !

Notre nouvelle méthode de paiement fonctionne avec MasterCard et Visa. Pour le moment, il n'est possible de ne payer qu'en Euros. Les Dollars arriveront bientôt.

Le paiement par carte bancaire sur Clever Cloud est rendu possible grâce à Paymill.

Pour plus d'informations, n'hésitez pas à nous contacter.

Since the beginning of Clever Cloud, we never went back on our beliefs. Europe needs a cloud hosting offer made by Europeans, to avoid the constraints imposed by the US.

Recently, PRISM program was unveiled to the public by Edward Snowden, who became one of the most wanted men by the US Government.

We aren't going to review here what PRISM is. Many articles have already mentioned it.

Lately, ZDnet has reposted an article first published in June 2011. Brief extract:

The question put forward:

Can Microsoft guarantee that EU-stored data, held in EU based datacenters, will not leave the European Economic Area under any circumstances — even under a request by the Patriot Act?

Frazer (Microsoft U.K.’s managing director) explained that, as Microsoft is a U.S.-headquartered company, it has to comply with local laws (the United States, as well as any other location where one of its subsidiary companies is based).

Though he said that "customers would be informed wherever possible," he could not provide a guarantee that they would be informed — if a gagging order, injunction or U.S. National Security Letter permits it.

He said: "Microsoft cannot provide those guarantees. Neither can any other company."

Actually, we can protect data of European users. And that is what we do. We are not using a cloud infrastructure based in the US or Ireland. All our datacenters are in France (Paris area) and are the property of a major french firm: Iliad.

We have worked hard to create a Europe based cloud offer and even if we want to grow internationally, we will still guarantee this privilege for those who want a total european cloud environment.

Your data can be accessed by the US Government if you are in one of the following cases:

• your company is american or wholly-owned by a US parent company
• whatever the nationality of your company, you host data in the US

The solution is quite simple: if you are a european based company and you don't want to share any information of your company or your customer privacy, you must host your application and data on the European soil in a datacenter owned by a European company.

Version française

Depuis le début de Clever Cloud, nous ne sommes jamais revenu sur notre volonté de départ. L'Europe a besoin d'un cloud fait par des européens, en réponse aux contraintes imposées par les États-Unis.

Récemment, le programme PRISM a été révélé au public par Edward Snowden, un employé de la NSA devenu au passage l'homme le plus recherché par les États-Unis.

Nous n'allons pas expliquer ici ce qu'est PRISM. Beaucoup d'articles l'ont déjà fait.

Dernièrement, ZDnet a republié un article premièrement publié en juin 2011. Ce qui suit en est un extrait traduit:

La question est la suivante :

Microsoft peut-il garantir que les données européennes, hébergées dans des datacenters européens, ne quitteront pas la zone économique européenne sous aucunes conditions – même sous la requête du Patriot Act ?

Frazer (directeur général Microsoft U.K.) explique que, comme Microsoft est une entreprise dont le siège social est basé aux États-Unis, elle doit se conformer aux lois locales (les États-Unis, ainsi que toutes les entreprises filiales du groupe basées ailleurs).

Bien qu'il ai dit que "les clients seront informés dans la mesure du possible," il ne peut pas garantir qu'ils le seront – si une censure, une injonction ou une lettre du U.S. National Security le permet.

Il a dit : "Microsoft ne peut pas fournir ces garanties. Aucunes compagnie ne le peut."

En fait, il est possible de protéger les données des utilisateurs européens. C'est même ce que nous faisons. Nous n'utilisons pas d'infrastructures basées aux États-Unis ou en Irlande. Tous nos datacenters sont en France (région parisienne) et sont la propriété d'une firme française : Iliad.

Nous avons travaillé dur pour créer une offre de cloud computing européenne et même si nous souhaitons nous développer à l'international, nous continuerons de garantir cette protection à ceux qui souhaitent un hébergement de leurs données sur le vieux continent.

Vos données peuvent être consultées par le gouvernement américain seulement si :

• votre entreprise est américaine ou est possédée majoritairement par une entreprise américaine;
• les données sont stockées sur le sol américan, peu importe la nationalité de votre entreprise.

La solution est très simple: si votre entreprise est basée en Europe et que vous ne souhaitez pas partager les informations relatives à vos clients (ou à votre entreprise), vous devez héberger vos applications et données sur le sol européen, dans un datacenter possédé par une entreprise européenne.

Here it comes! Dzone's definitive guide to PaaS & IaaS solution has been officially launched today.

Clever Cloud has participated to the achievement of this guide and you can find all the informations about us inside it.

Read what Dzone said about it:

DZone's Definitive Guide Helps You Make the Right Cloud Decision for Your Organization

Have you ever tried sifting through the hundreds of cloud solutions available in today’s market?
There are so many categories of cloud providers that it’s hard to know if you’re researching the right one’s for > your use case.

So how do you distinguish the contenders from the pretenders? Even if you have nailed down the type of cloud > provider you need, you’re still facing a litany of choices.

The cost and time savings of choosing the right cloud provider can revolutionize your business and drive significant > new profit, but the selection process is daunting. DZone observed many developers and IT professionals struggling to find the right solution for their organization, so we decided to mount this unprecedented research project to create a definitive guide to cloud providers.

The result is DZone's Definitive Guide to Cloud Providers.

• 100 Pages of Cloud Solution Analysis
• 9 Categories of PaaS and IaaS Analyzed and Compared
• 35+ of the Most Active Cloud Solutions and Their Feature Sets
• Research from 400+ IT Professionals on Cloud Preferences.

Get your FREE copy of this guide and make the best decision for your organization.

Lire la version française

The dotConferences are always crazy. The first one of 2013 is the dotScale one. This cloud conference dedicated to developers takes place the 7th and 8th June 2013. The attracting mix is still the same : the best tech speakers in an amazing environment, the Paris “théâtre des variétés”. There are some new speakers and we are very proud to see our CEO Quentin Adam being part of them.

"No marketing speeches, no buzzword cover-ups"

Why is the dotScale so special and interesting ? For us, it is the concept itself: a conference which gives a voice to hardcore developers, more specially to those who work hard to offer innovative cloud solutions.

Where the magic takes place.

The tech conference to supersize your apps

This event’s goal is to offer an affordable and unique conference to the developpers. It's also the occasion to understand the technical choices of the platforms they use for their own apps. Thereafter optimise them in order to make them more scalable by taking full advantage of the underlying platform.

Some of the best speakers you could expect

As we mentionned at the beginning of the article, Quentin will be a part of the event as a speaker. He will introduce Clever Cloud to the devs. The complete list of speakers is on the website. Finally, just know that some workshops will occur the day after the conferences (8th June).

We also wanted to thank Sylvain Zimmer for having contacted us

Version française

Les dotConferences sont toujours incroyables. Cette année, la première est la dotScale, la conférence cloud dédiée aux développeurs qui aura lieu les 7 et 8 juin 2013. La recette ne diffère pas énormément: le meilleur de la technique dans un décor incroyable, à savoir le théâtre des variété de Paris. Pour cette édition dédiée au cloud, nous sommes très fier d'y voir Quentin Adam (CEO de Clever Cloud).

Pas de discours marketing, pas de couverture de buzz

Ce qui rend la dotScale si spéciale (et si intéressante à nos yeux) c'est son concept lui même: proposer une conférence qui donne la parole aux hard développeurs, en clair à ceux qui mettent les mains dans le cambouis pour proposer des solutions cloud innovantes.

La conférence technique pour maximiser vos apps

L'objectif de cet évènement est de présenter une conférence pour les développeurs, abordable et unique. C'est aussi l'occasion de comprendre les choix techniques des plateformes qu'ils utilisent pour leur propres applications et donc de les optimiser, de les rendre plus scalables.

Les meilleurs speakers seront présents

Comme nous l'avons évoqué au début de ce billet, Quentin participe à l'évènement en tant que speaker. Il y présentera Clever Cloud aux développeurs. Pour connaître la liste des speakers présents, rendez-vous sur le site de l'évènement.

Sachez également que pour cette édition aussi des ateliers auront lieux le lendemain des conférences (le 8 juin).

Nous souhaitions enfin remercier Sylvain Zimmer de nous avoir sollicité

Le Frenchweb Tour a fait étape à Nantes et s'est intéressé à Clever Cloud. Quentin ADAM est donc passé devant les caméras du magazine des professionnels du digital pour rappeler ce qui compose notre offre et présenter nos enjeux à venir.

Retrouvez l'intégralité de l'article sur Frenchweb.