This represents a major milestone that culminates three years of preparation and is part of our broader strategy to maintain complete control over our Paris region's network infrastructure.

Why We Made This Change

In Clever Cloud's early years, we delegated network responsibility to partners. This approach made sense: it allowed us to accelerate development, focus on cloud services, and avoid investing in expertise we hadn't yet mastered. But as our infrastructure grew, the limitations of this dependency became clear. We had no control over strategic decisions — how traffic was routed across the Internet, which paths our packets took, or how quickly we could respond to failures. Every modification, every incident required the involvement of a third party.

We decided to take this responsibility back. In doing so, we gained several concrete advantages. We optimize costs through direct management of our transit and peering relationships. We define our own routing policy instead of following an intermediary's constraints. We resolve incidents ourselves, without waiting for external providers. And we achieve complete control of our network stack — the same way we progressively took control of our servers and datacenters over the past few years.

But this transition isn't just about our operational independence. It brings immediate, tangible benefits for you. The most critical is resilience. Previously, all traffic was routed through a single provider. Any incident on their side impacted every service we offered. We now maintain four upstream providers across three datacenters in the Paris area. When one link fails — and it has happened over the past year — traffic automatically shifts to available alternatives without customer-impacting interruption. We can even withstand the simultaneous loss of multiple transit links.

Beyond redundancy, we gain control over routing itself. We now decide how your traffic reaches its destination. This allows us to optimize paths for lower latency and better performance, and to adjust those decisions based on your specific needs and our network topology. We respond to congestion, to changing conditions, and to your requirements in real time.

Finally, there is the question of operational responsibility. Network issues no longer require us to wait for an external provider to acknowledge and resolve them. Public network failures fall directly under our responsibility — we detect them, analyze them, and fix them ourselves. This directly reduces the time between problem and resolution, which means less downtime and better reliability for our customers.

Operating Your Own Network on the Internet

To operate as an independent network on the Internet, organizations must work with a Regional Internet Registry (RIR). RIRs are responsible for allocating and managing IP addresses and AS numbers within specific geographical regions.

There are five RIRs worldwide:

• RIPE NCC — Europe, Central Asia, and the Middle East
• ARIN — North America (United States, Canada, and the Caribbean)
• LACNIC — Latin America and the Caribbean
• APNIC — Asia-Pacific region
• AFRINIC — Africa

For Clever Cloud, since our infrastructure is primarily in Europe, we work with RIPE NCC (Réseaux Internet Publics Européens).

Allocated Address Space

As a member of a RIR, organizations receive allocations of both IPv4 and IPv6 address space. For RIPE NCC members, this typically includes a /24 block of IPv4 addresses (depending on the availability of such a block) and a /29 block of IPv6 addresses. These allocations are managed under your membership and can be used to operate your network globally.

Creating Our Autonomous System

The groundwork for this transition began several years ago. In 2019, we created our RIPE NCC account to become a LIR (Local Internet Registry). This gave us access to a /24 IPv4 block (91.208.207.0/24) and a /29 IPv6 block (2a0f:d0c0::/29).

Then, in 2022, we registered our Autonomous System Number (ASN) with the Regional Internet Registry for our region. Our AS number is AS213394. Here is the aut-num object:

> whois AS213394

aut-num:        AS213394
as-name:        CleverCloud
org:            ORG-CCS42-RIPE
import:         from AS29075 accept ANY
import:         from AS3257 accept ANY
import:         from AS3356 accept ANY
import:         from AS43424 accept ANY
export:         to AS29075 announce AS213394:AS-CLVRCLD
export:         to AS3257 announce AS213394:AS-CLVRCLD
export:         to AS3356 announce AS213394:AS-CLVRCLD
export:         to AS43424 announce AS213394:AS-CLVRCLD
admin-c:        QA171-RIPE
tech-c:         QA171-RIPE
status:         ASSIGNED
mnt-by:         RIPE-NCC-END-MNT
mnt-by:         mnt-fr-clvrcldnet-1
created:        2022-11-28T08:24:23Z
last-modified:  2025-02-25T16:36:15Z
source:         RIPE

An Autonomous System Number (ASN) is a unique identifier for networks on the Internet. It's required to announce routes via BGP — the protocol that makes inter-network routing possible. Creating an AS early on allowed us to plan for this eventual transition and prepare the necessary infrastructure in advance.

Now that we have an ASN, we can start announcing our prefixes to other networks on the Internet using the BGP protocol.

The Role of the RIPE Database

The RIPE NCC maintains a public database of routing objects (like the aut-num object above). Among these objects are route objects, which specify which AS is authorized to announce a particular IP prefix. In practice, these entries are primarily used by network operators and transit providers to build routing policy and filters (IRR-based filtering) to accept or deny announcements from their peers. This is one way to try to prevent BGP hijacks. By applying those filters to the routes you receive from your peers, you can limit the propagation of a prefix that originates from the wrong ASN.

Let's say that Org A owns 192.0.2.0/24 and announces it to Transit X. Transit X applies a filter on routes learned from Org A to only accept the IP prefixes that Org A has in its RIR database. This way, if Org A starts announcing a prefix it doesn't own (let's say our public prefix, 91.208.207.0/24), then Transit X is supposed to reject that route. This helps prevent the bad route from being propagated and traffic from being forwarded to the wrong entity.

However, not all networks implement IRR filtering. Better mechanisms like ROA (Route Origin Authorization) exist to address this gap.

The BGP Protocol: How the Internet Routes Traffic

To understand how we announce our prefixes on the Internet, it's essential to understand BGP — the Border Gateway Protocol. BGP is the de facto standard routing protocol of the Internet. It allows networks (Autonomous Systems) to exchange information about which IP prefixes they own and how to reach them.

BGP works in both directions. When we announce to our peers and transit providers "we own 91.208.207.0/24", this announcement travels through the Internet from network to network. Each network that forwards our announcement prepends its own AS number to the AS_PATH — a list showing the sequence of networks a packet traverses to reach us. For example, OVHcloud (AS16276) sees the path [AS29075, AS213394]: traffic goes through one of our transit providers (AS29075), then reaches us (AS213394). Each network that forwards the announcement updates it this way, building a complete path. Here's an example using the OVHcloud Looking Glass service:

> show route for 91.208.207.0/24 all

91.208.207.0/24    via 172.18.16.0 on eno1 [lil1_rbx1_bagg1_8k 2025-12-25] * (100/0) [AS213394i]
    Type: BGP unicast univ
    BGP.origin: IGP
    BGP.as_path: 29075 213394
    BGP.next_hop: 172.18.16.0
    BGP.med: 161
    BGP.local_pref: 40
    BGP.community: (0,0) (29075,18000) (65535,65281)
    BGP.23 [t]: 00 00 b8 6e
                   via 172.18.16.64 on eno1 [lil1_rbx8_bagg1_8k 2025-12-25] (100/0) [AS213394i]

At the same time, we receive announcements from other networks about their prefixes and the paths to reach them. This builds the opposite view: when we need to send traffic outbound, we know which path to take to reach any given destination. Here's an example with one of OVHcloud prefixes:

> /routing/route/print detail where dst-address=5.39.0.0/17 and active

Ab   afi=ip4 contribution=active dst-address=5.39.0.0/17 routing-table=main pref-src=185.133.116.2 gateway=213.242.111.201 immediate-gw=213.242.111.201%sfp28-6 distance=20 scope=40 target-scope=10 belongs-to="bgp-IP-213.242.111.201"

      bgp.as-path="3356,16276" bgp.communities=3356:2,3356:2066,3356:22,16276:40001,3356:100,65002:7018,3356:123,3356:901,65002:701,65000:64990,65000:64995,65000:64996,3356:502 .med=0 .atomic-aggregate=no .origin=igp

Here the network path OVHcloud uses to reach us is different from the one we use to reach them.

The Migration Process

Our IP prefixes were entirely managed by our historical provider. While we legally owned the addresses, we delegated the technical responsibility of announcing them to the Internet to this single provider. This meant:

• Our provider's AS (AS43424) was listed as the origin of our prefixes in the Internet routing tables
• All traffic destined for our services or outgoing to the Internet had to flow through their infrastructure

Clever Cloud Services
   |
   | all inbound/outbound traffic
   v
Historical Provider (AS43424)
   |
   | originates: 91.208.207.0/24 (origin AS43424)
   v
Internet

We now want our ASN to be the origin of the announcements. To migrate safely, we planned a three-step migration. The requirements were simple: we could not accept any customer-impacting interruption.

Migrating a prefix between ASNs

To migrate a prefix from one AS to another, we needed to modify its route object in the RIPE database. The procedure was straightforward but required careful timing.

First, we created a second route object in the RIPE database for our 91.208.207.0/24 prefix. Now both ASNs were registered as authorized to announce the same prefix — both our historical provider's AS and our own AS (213394).

These routing objects are publicly queryable via the whois command or through the RIPE web interface. For example, running whois -h whois.ripe.net -T route 91.208.207.0/24 returns both registered objects:

❯ whois -h whois.ripe.net -T route 91.208.207.0/24
% Information related to '91.208.207.0/24AS213394'

route:          91.208.207.0/24
mnt-by:         mnt-fr-clvrcldnet-1
descr:          CleverCloud subnet
origin:         AS213394
created:        2025-01-15T10:29:14Z
last-modified:  2025-01-15T10:29:14Z
source:         RIPE

% Information related to '91.208.207.0/24AS43424'

route:          91.208.207.0/24
mnt-by:         mnt-fr-clvrcldnet-1
mnt-by:         MAGICRETAIL-MNT
descr:          CleverCloud subnet
origin:         AS43424
created:        2020-02-13T09:06:33Z
last-modified:  2020-02-13T09:06:48Z
source:         RIPE

Once this second route object was registered and propagated across the Internet (i.e., network operators pulled an up-to-date version of the RIPE database to build their routing filters), our new transit providers could see that our ASN was authorized to announce this prefix. At that point, we could begin announcing the prefix through our own infrastructure.

If we didn't create that route object, our route announcement might have been rejected and we could have been flagged as BGP hijackers.

Announcing Through Our Historical Provider

Once the second route object was propagated, we performed the first step during the night of January 16, 2025: we began announcing the prefix ourselves via BGP to our historical provider. This was still using the same transit path, but now with Clever Cloud AS213394 originating the announcements instead of our historical provider. Our historical provider continued to relay the prefix, but now received it from us rather than announcing it directly.

Clever Cloud Services (AS213394)
   |
   | originates: 91.208.207.0/24 (origin AS213394)
   v
Historical Provider (AS43424)
   |
   | re-announces: 91.208.207.0/24 (origin AS213394)
   v
Internet

This first phase served as validation — if any issues arose, we could quickly revert without impacting other transit paths.

Announcing Through Our Own Transits

A few days later, during the night of January 21, 2025, we took the final step: we began announcing the prefix through our own dedicated transit connections.

Clever Cloud Services (AS213394)
   |
   | originates: 91.208.207.0/24 (origin AS213394)
   |
   +---+---+---+
   |   |   |   |
   v   v   v   v
  T1  T2  T3  HP
(Transit providers + historical provider)
   |   |   |   |
   +---+---+---+
   |
   v
Internet

We now announce our prefixes directly to four upstream providers (three transit providers, T1/T2/T3, plus our historical provider HP). Traffic flows across all paths, and we have full control over routing decisions and redundancy.

Throughout both phases, we observed no customer-impacting interruption. The BGP protocol's built-in redundancy and the gradual nature of the transition ensured that traffic flowed smoothly regardless of which path was preferred at any given moment.

Complete Internet Routing Visibility

As part of Phase 2, our three primary transit providers began sending us a "full view" of the Internet's routing table. This is the complete set of all publicly announced IPv4 and IPv6 prefixes — roughly ~1 million IPv4 routes and ~220,000 IPv6 routes.

A full view gives us unprecedented visibility into how the Internet is structured and allows us to make sophisticated routing decisions. Rather than relying on a single provider's perspective, we now see all available paths to reach any destination on the Internet.

With this information, we are able to:

• Choose optimal paths for our outbound traffic based on our network topology and preferences
• Implement traffic engineering to direct flows through specific transit providers
• Respond dynamically to network conditions and congestion
• Balance load across our four transit connections based on real-time routing data

This fine-grained control over our routing policy is a direct result of operating our own AS and managing our own announcements — exactly the kind of operational independence we sought when we began this transition.

One Year Later

Nearly a year into operating our own network announcements, the transition has proven successful. We have experienced no major incidents, and our infrastructure has proven resilient. When minor issues have occurred — such as packet loss through a specific transit provider or the temporary loss of a transit link — traffic has automatically rebalanced across our remaining connections. We have been able to detect and respond to these issues directly, without waiting for a third-party provider to take action. Our customers experienced no customer-impacting interruption. This ability to own our problems and resolve them quickly is perhaps the greatest benefit we've gained.

What's Next

This transition is far from finished. We have several roadmap items ahead of us:

• Increased network capacity to handle growing traffic demands
• BGP peering with other networks to optimize traffic locally without paying for transit
• ROA (Route Origin Authorization) deployment to cryptographically sign our route announcements and prevent unauthorized parties from hijacking our prefixes
• RPKI (Resource Public Key Infrastructure) validation to ensure the legitimacy of announcements we receive from other networks and protect against prefix hijacking attacks
• IPv6 expansion, both inbound (accepting IPv6 traffic) and outbound (sending IPv6 traffic) — a transition we will roll out in phases

Conclusion

In early 2025, Clever Cloud completed its transition to fully independent network operations. We now announce our own IP prefixes through four upstream providers, giving us full authority over how traffic flows in and out of our infrastructure.

For our customers, this translates to better reliability and faster problem resolution in our Paris region. When network issues occur, we handle them directly — and our multi-provider redundancy ensures traffic keeps flowing even when incidents occur.

This milestone is just the beginning. We're already working on BGP peering to optimize local traffic, ROA signing and RPKI validation to strengthen routing security, and IPv6 expansion to fully embrace dual-stack connectivity. We're building a network as robust and self-sufficient as the rest of our infrastructure — and we're excited about what comes next.

tl;dr: On March 21th 2022 the Cellar C1 cluster will reach its end of life. So we ask you to perform a migration to a newer cluster Cellar, which will also improve performance. The C1 cluster did not accept new add-ons since the 20th January 2019.

In fact, data need to be migrated from this old add-on to a new Cellar add-on. Newly created Cellar C2 add-ons come with various improvements :

• A better S3 protocol support (including the AWS V4 signature)
• Improved upload and download performances (x3 for upload, x2 for download)
• Improved resilience and availability of your data (Data is now replicated across two datacenters more than 20km apart)

How to migrate my data?

We can help you to migrate your data by syncing it directly on our side. To do that, reach the support and include in your message source and destination add-ons, including the buckets to migrate. The support team is here to help.

If you wish to migrate on your side, or at least keep your buckets synchronized, we built a simple tool to help you: Cellar migration tool.
You can run this tool as many times as you need. It will only synchronize objects that are different between the source and the destination buckets.
If you do not feel comfortable using it, you can also use the s3cmd sync command from the s3cmd tool.

If your application handle it, we encourage you to upload new objects as soon as possible to the new bucket. Then when you need to query that object, your application can query both buckets (old and new) to get it. You can also store the complete URL to make this easier. This should help you transition from one bucket to another without downtime.

Please note that we can't make sure that the buckets names you use will be available on the destination cluster. If you have a name conflict, please contact us and we will work something out.

A few days before the deadline, we will have short service brown-outs to remind customers that the service is going to be shut down. Those brown-outs will be announced on our status page a few days before. Make sure to subscribe to Status Updates to receive a notification.

What will happen if I can't do the migration?

If you can't do the migration or have any questions about it, we strongly recommend that you contact our support team via the console.
Before shutting down the cluster, we will backup your data and keep it for 6 months. Our support team will be able to provide you a download link or re-inject the data in a new bucket if you wish to recover it.

Clever Cloud applications to run your jobs

Enhance your Clever Cloud deployments workflow

pipeline {
  environment {
    CLEVER_TOKEN = credentials('CLEVER_TOKEN')
    CLEVER_SECRET = credentials('CLEVER_SECRET')
  }

  stage('clever-tools') {
      steps {
        script {
          sh 'npm install -g clever-tools'
       }
     }
  }

  stage('tests') {
    // Your tests steps
  }

  stage('deployment') {
    steps {
      script {
        // Deploy the application
        // A .clever.json file must exists in the repository
        sh 'clever deploy'
      }
    }
  }
}

Built with the classic features you love

Pricing

What's next?

A connection pool will cache your database connections and keep them open for future requests

Configure ProxySQL

• CC_MYSQL_PROXYSQL_USE_TLS: A boolean (true or false) to enable TLS between ProxySQL and your MySQL add-on. Defaults to true.
• CC_MYSQL_PROXYSQL_MAX_CONNECTIONS: An integer which defines how many maximum connections ProxySQL will open to your MySQL add-on. Defaults to 10. You can refer to our ProxySQL documentation to learn more about how you should compute the maximum connection value when auto scalability is involved.

Examples

PHP using PDO

<?php
// This variable is injected during the deployment
$socket = getenv("CC_MYSQL_PROXYSQL_SOCKET_PATH");
// Get the database name from the environment
$db = getenv("MYSQL_ADDON_DB");
// Get the database user from the environment
$user = getenv("MYSQL_ADDON_USER");
// Get the database password from the environment
$pass = getenv("MYSQL_ADDON_PASSWORD");
$dsn = "mysql:unix_socket=$socket;dbname=$db";
try {
  $pdo = new PDO($dsn, $user, $pass);
} catch (PDOException $e) {
  throw new PDOException($e->getMessage(), (int)$e->getCode());
}

Wordpress

// To connect using a unix socket, the syntax is: `localhost:/path/to/socket`
define('DB_HOST', "localhost:" . getenv("CC_MYSQL_PROXYSQL_SOCKET_PATH") );
// Get the database user from the environment
define('DB_USER', getenv("MYSQL_ADDON_USER"));
// Get the database password from the environment
define('DB_PASSWORD', getenv("MYSQL_ADDON_PASSWORD"));
// Get the database name from the environment
define('DB_NAME', getenv("MYSQL_ADDON_DB"));

Node.js

const mysql      = require('mysql');
const connection = mysql.createConnection({
  // Get ProxySQL unix domain socket path from the environment
  socketPath : process.env["CC_MYSQL_PROXYSQL_SOCKET_PATH"],
  // Get the database user from the environment
  user       : process.env["MYSQL_ADDON_USER"],
  // Get the database password from the environment
  password   : process.env["MYSQL_ADDON_PASSWORD"],
  // Get the database name from the environment
  database   : process.env["MYSQL_ADDON_DB"]
});
connection.connect(function(err) {
  if (err) {
    console.error('error connecting: ' + err.stack);
    return;
  }

  console.log('connected as id ' + connection.threadId);
});

Metrics

Documentation

Conclusion

Parse Server

Deploy on Clever Cloud

1. First, you need to clone this repository (or use an existing one) and modify the Parse Server instanciation:

   var api = new ParseServer({
     databaseURI: process.env.MONGODB_ADDON_URI, // Use the MongoDB URI
     cloud: process.env.CLOUD_CODE_MAIN || __dirname + '/cloud/main.js',
     appId: process.env.PARSE_APPID, // Use environment variable to set the APP_ID
     masterKey: process.env.PARSE_MASTERKEY // Use environment variable to set the PARSE_MASTERKEY
   });
   

2. Open the Clever Cloud Console, create an account if you don't have one yet
3. Create a Node.js application and a MongoDB addon
4. Add these two environment variables: PARSE_APPID: <parseAppID>, PARSE_MASTERKEY: <parseMasterKey>
5. Follow the instructions about adding the remote to your local git repository
6. Deploy it: git push clever master and head to your application's logs

You may have noticed major updates on the Clever Cloud Console these last weeks. Along with the quick search feature, keyboard shortcuts and a new UI, we introduced the use of service workers to reduce the load time of the Console.

Service workers you said? Surely you mean Web Workers, right?

No! Service workers are scripts which are run by your browser, in the background. They are completely separated from the web pages of your site and have multiple uses. You can use them for HTTPS proxying, push notifications, or even background syncing.

Today, we will cover HTTPS proxying.

The Console should load faster

When you load the Clever Cloud Console, we need to fetch data (the user, its organisations / apps / addons…) to bootstrap the whole application. If you have a lot of applications / belong to a lot of organisations, this may take a while, up to several seconds ("a lot" can mean ~200 apps for some of ourusers). This data isn't updated a lot. Most of our customers are using the Console to look at the logs or configure their applications. So it needs to be fast for them to access / set the information they want.

Here come the service workers. They can cache the response of any HTTPS request that is emitted from your application (which can be used to build offline apps). What we did is that any huge XHR request done when the Console is loading is now served from the cache if it exists.

How does it work?

• These new APIs (Service Workers, Cache API, Fetch API) are heavily using ES6 Promises, you should be familiar with them
• Incidentally, you can use ES6 because browsers that support service-workers are also implementing mainstream ES6 features
• You need to use a recent browser: Chrome 42+, Firefox 44+
• Service Workers are HTTPS only, they won't work on HTTP requests. Chrome will allow http://localhost as a secure origin though.

How to debug

• You can check "Enable Service Workers over HTTP (when toolbox is open)" on Firefox Devtools to use service workers on any HTTP request.
• Chrome will only allow localhost or HTTPS urls. Good thing that HTTPS is available on *.cleverapps.io.
• Firefox and Chrome have an endpoint to list service workers: Firefox: about:serviceworkers, Chrome: chrome://inspect/#service-workers
• You can use regular console.log() to log from the service worker.
• You won't be able to see intercepted requests in the Network panel of Firefox (as of Firefox 45.0a1).

The code

First, we need to setup our service worker and ask the browser to register it (in your existing javascript application):

  navigator
    .serviceWorker
    .register('/service-worker.js')
    .then(navigator.serviceWorker.ready)
    .then(registration => {
      console.log('Server worker has been registered');
    });

You don't have to worry about multiple registrations: if a service worker has already been registered, the browser will simply ignore it.

Once this is done, we have to create a service-worker.js file. Service Workers are event based. Two events will be useful in our case: install and fetch. install will allow us to initialize our service worker (like pre-caching assets we haven't already loaded). fetch will be triggered each time a request is intercepted for the current scope.

We will use the Cache API to cache requests / responses.

'use strict';

const CACHE_URLS = [
  "/img/img1.png",
  "/img/img2.png",
  "/users/me"
];

const CACHE_NAME = "cc-cache-test";

self.addEventListener('install', event => {
  event.waitUntil(
    caches
      .open(CACHE_NAME)
      .then(cache =>{
        cache.addAll(CACHE_URLS);
      })
      .catch(e => console.error("Couldn't install the service worker, reason:", e));
  );
});

self.addEventListener("fetch", event => {});

Here, during the installation step, the service worker will download and cache the CACHE_URLS urls even before the user requests them. Now, we need to tell our SW to use the cache whenever we have a cached version of the request or to fetch it if we don't. We can use the great HTML5 Fetch API:

self.addEventListener("fetch", event => {
  event.respondWith(
    caches.open(CACHE_NAME)
      .then(cache => cache.match(event.request))
      .then(response => {
        if(response){
          return Promise.resolve(response);
        } else{
          return fetch(event.request).then(res => {
            if(res && res.status === 200){
              caches.open(CACHE_NAME)
                .then(cache => {
                  cache.put(event.request, res);
                });
            }
            return res.clone();
          });
        }
      })
  );
});

What we are doing is to open the cache and then try to match the current request. If we have a match, we return the response associated to the request. If we don't, we fetch the request, check its response code and save it into the cache if it succeeded. Next time, it will load faster!

Note that we have to use res.clone();. This is because the response is a stream which can be read only once. Here, we want to store its data into the cache AND return the same data to the browser. This won't work unless we .clone() it first.

Now, our service worker is ready to be used.

Sounds perfect but…

A major drawback is that you need a quite recent browser and these API may differ between browsers. At the time of writing, this won't work on Safari (any version), Firefox stable (aurora/dev has some support), Opera, Internet Explorer (Edge does support some features). You will have to handle these incompatibilities yourself.

But, even if service workers are not yet supported by all browsers, your application will still be able to run in a normal way. Only proxying and cache features will be affected, requests will be done as they were before. This is completely backwards compatible.

How do we use it at Clever Cloud

We can't store all of the data or cache invalidation will be a mess to handle. Instead, we only store a few defined requests. When we load the Console, we use the cache, then wipe and update it in the background. The user can use the Console with quite fresh data and the UI will be updated as soon as we have the new one.

This feature allowed us to speed up the initial load of the Console, going well under 1 second if the cache exists. In a near future, we could also use service workers with the Notifications API to display application deployments's state even when the Console is not open in your browser.

More reading

To learn about service workers, I used a few links:

• Service Workers
• Cache API
• ES6 Promises
• HTML5 rocks (may be a little out of date but still accurate and well explained)

Lately, a lot of developpers asked us about Meteorjs support on Clever Cloud. This is indeed a growing technology out there, so I decided to test it myself.

What is Meteorjs ?

Meteor.js is based on Nodejs and is a real-time cross-platform web application framework (Web, Android and iOS). One of its main features is to automatically propagate data changes to clients in real-time or even query the database from the client (well, the client has a cache of the database which will update the remote one). It is an easy framework to build reactive applications

How to deploy on Clever Cloud

As an example of a large Meteor application, I will use TelescopeJS. It's a social news application you can configure the way you want. I'll use the version v0.14.2 since it does not require MongoDB 3.0. This is a version we will provide in a near future.

1- Clone

So first, git clone https://github.com/TelescopeJS/Telescope && cd Telescope && git checkout v0.14.2 and run it: meteor run. Then open http://localhost:3000, you should see the default page with some examples.

2- Install and build

To make it run on Clever Cloud, we have to make our own install script. This script will run when you deploy your application and build what's needed. Create an install.sh file and paste the following lines (or download it from Github):

#! /bin/bash

# Current path
currentPath=$(realpath ./)

# Install Meteorjs
curl https://install.meteor.com/ | sh
export PATH=/home/bas/.meteor:$PATH

# Install demeteorizer
cd ~/ && npm install demeteorizer

# Go back to our project
cd "$currentPath"

# Note: When using "meteorhacks:npm"
# to prevent the error: "unknown package: npm-container"
# (described in https://github.com/meteorhacks/npm/issues/49)
# uncomment the two following lines:
#meteor remove npm-container
#meteor run

# demeteorize the app
~/node_modules/.bin/demeteorizer -a "my_app" -o my_app/

# Go inside our demeteorized app to install modules
cd my_app/

# Install modules
npm install

This script will install Meteorjs on our platform, demeteorize the app (i.e. convert it as a regular node.js application) and install its modules. If you are using the package npm-container from meteorhacks, you HAVE to uncomment lines 20 and 21 (this is not our case here). Do not forget to do a chmod +x install.sh to give it execution rights.

Now we have to create our package.json (which is the file which describe your application for NPM): npm init. Open it and create a scripts section:

"scripts":{
  "install": "./install.sh",
  "start": "node my_app/main.js"
}

(my_app/main.js is a file generated by demeteorizer, do not modify this line)

Then, you can commit your changes: git add package.json install.sh && git commit -m "Clever Cloud setup"

Configuration

Once done, we need to create a Node.js application and a MongoDB addon and configure it. Open the dashboard and:

Addon

• Add an addon
• Select MongoDB, choose your plan and name it.
• Click it in the blue pane on your left, go into its configuration tab and copy somewhere the Connection URI field

Application

• Add an application
• Choose node.js for the language
• Choose the scalers you want (the default configuration is enough most of the time)
• Name it
• We don't need an addon since we've just created it
• Environment variables: You have to create 2 of them: ROOT_URL (url of you application) and MONGO_URL (the Connection URI field you saved)
• Follow instructions to add the remote repository, git push and it will deploy.

Your application should now be deployed, feel free to contact our support if you have any troubles!