When you deploy an application on Clever Cloud, it listens by default on port 8080 and responds to HTTP(S) requests. In the past, customers have asked us for an additional TCP listening port. Their goal was to handle specific protocols or interactions.

At first, we responded to these requests on a case-by-case basis. Two years ago, we added a TCP port forwarding feature to our Clever Tools CLI: as we explained then, one command is enough to open a port.

However, we were regularly asked to simplify the access to this feature by adding it to our web interface: the Console. It's done. A "TCP Redirections" section is now available in the menu of your applications:

It allows you to create a redirection in the default namespace (used by all custom domain names) or cleverapps (used by all cleverapps.io domain names). Both can be used simultaneously.

Once the redirection is created, an external access port will be assigned to the application, which will systematically redirect to its internal port 4040. Note that this feature is still in a testing phase. It can be used freely and is not charged.

It is now possible to force HTTPS redirection! No more .htaccess black magic, no redirection handling code… Let's have a tour of this new feature.

Forcing HTTPS on Clever Cloud

Let's start practical. There are two ways to achieve our goal.

Using the CLI

In your linked application, in your own terminal just type in clever config set force-https enabled.

clever config is a new CLI command that allows you to display in your console the current configuration of your application. You can edit any setting with clever config set {name} {value} and bulk edit with clever config update [options].

Here we just set the force https option to enabled and if we want to set if off we can just clever config set force-https disabled.

If this does not work for you, make sure you are running version 2.5.0 or newer (with clever version).

Using the Clever Cloud console

In the information page of each application, you will find a checkbox form with options you can tune in and out. One of them is Force HTTPS. Enable its checkbox and save.

From now on and as long as you do not disable it, every non-secured HTTP request to this application will be redirected to HTTPS with a 301 Moved Permanently status code.

How the magic happens

The Clever Cloud way

The redirection is handled at the reverse proxy level so you don't need to update your application to use it. Each time the browser will request a resource using HTTP, it will get a 301 response back with the same resource prefixed by https in the Location header field. The 301 redirection is recognized as the best practice for HTTPS upgrade.

Why enforce HTTPS

Before explaining why it is important, I shall provide a definition of HTTPS.

Simple definition

First of all, HTTPS is an extension of the HTTP protocol. Which itself is the application protocol the world wide web is relying on for communications. Full definition to be found on wikipedia.

The main difference between HTTP and HTTPS communication is encryption.

Using HTTPS, the communication is bidirectionaly encrypted between the client and the server. Both the headers and the response/request data are ciphered. This is achieved using TLS cryptographic protocol in addition to operations involved in a simple HTTP transmission.

The identification process requires the server administrator to create a public key certificate signed by a trusted certificate authority.

We have automated this part. So every time you create a new application on Clever Cloud, a cleverapps.io subdomain name is given to your application and comes along with encryption because a certificate covers cleverapps.io and all its subdomains. And each time you add a custom domain to your application like example.com, Clever Cloud asks Let's Encrypt for a TLS public key certificate that we automatically add to your application's configuration on our reverse proxies. Thanks to that, you can accept HTTPS requests on a brand new application without further configuration.

Enforcing HTTPS is just the beginning

I explained to you how HTTPS enforcing was working on Clever Cloud and that felt very simple, right?

To be honest this is because the tech team has decided only to handle the first step of the process.

Strong security on an application requires knowledge on many topics.

Sometimes, your application itself will link to HTTP content, which will result in mixed-content. When HTTP resources are served by the application on a page requested using HTTPS the browser will usually not load those resources.

You will also probably want to know more about HTTP Strict Transport Security (HSTS), and the Content-Security-Policy header.

You can start by reading this great article from Scott Helme to start your journey. If you cannot handle advanced security yourself, think about asking for the help of a security expert.

HTTPS is good for everyone, except hackers

In 2020 the HTTPS protocol is ubiquitous. It's more and more widely used thanks to the Let's Encrypt initiative which made it free for everyone; which makes the web more secure for both applications creators and clients.

The clients know they can trust the integrity of the content that's being displayed to them and feel safer about using the Internet in general. This safety feeling extends to their privacy. Today the regular user's main concern is about what the owner of the website do with their data. Not about that black hooded bad guy they were freaking out about a few years ago. The most used websites have raised their confidence about communications ciphering to such a level it's now the norm. Everyone puts credit-card numbers in forms eyes wide shut.

Yeah, but me ? Having a website to offer to the world, I want to meet my client’s expectations, of course. But HTTPS has more to offer me. From the SEO perspective, having it will naturally boost ranking. I also ensure my user's privacy and confidentiality. Most importantly, I can trust that the data I receive from my client has not been altered. That doesn’t mean that I shall trust my user intentions obviously. But now if I need to watch out for a hacker, it will not come from a man in the middle or this kind of attack.

Anyway, this is everywhere now and already almost mandatory. Take this train now! This feature is free, does not require extra code and works out of the box with the automatically generated Let's Encrypt certificates.

Time for some exciting new features! We've been working for a while now on giving more insights to your application's activity. Is your application used? Where? Which IPs are accessing it? Even the response time is here! In this post, I am presenting to you what's new and how to use it at best.

Console: new tiles and improvements

We've been building new tiles for both organizations and overview pages. These new tiles rely on web components which are open-source. You can embed each of these components easily in your product to show to your customers. You can find each of our components here: https://www.clever.cloud/developers/clever-components/.

Please note that these are in beta, so bear with us as we fix possible hiccups over time!

We are also developing a new type of ACLs, built on top of our next-gen auth product, allowing you to make integrations easier. Stay tuned!

Geolocation of requests

This one may be the most obvious change: there is a near-real-time map that shows dots for requests and their location around the world. In the organization's overview, you can see requests of all your apps combined.

There is also a heatmap that shows the density of the traffic location over 24 hours. Real-time is nice, but having a track of what's happened can be pretty handy.

HTTP Response codes

Here we show you the distribution of HTTP status codes in the responses of your apps. It is displayed over 24h. If you click on a status code in the legend, it will hide it from the chart. Pro tip: If your shift+click on a HTTP code in the legend, it will unselect all the other codes.

HTTP Requests

This graph represents the variation of HTTP requests on your app over 24h, with a time window of a 2, 3 or 4 hours for each graph, (depending on your windows size, responsive ftw).

Access logs & tools

What is an access log?

An access log records all requests that people or bots have requested from an application. When you are using Clever Cloud, your application's requests transit via our load-balancers. They receive the incoming network traffic and route it to each application. For legal reasons, we have to keep track of each request for at least a year.

Retrieving access logs, before

When a customer needed the access logs, the original process was to dive into a vast logfile and find it ourselves. But now, each Clever Cloud user can retrieve its access logs, and much more.

Retrieving access logs, today

We introduced Metrics a few years ago, a tool built into the web console to give monitoring data to our users. Metrics relies on Warp10, a time-series database built for this kind of usage. The access logs are now stored into Warp10, as it's a part of Metrics.

On the Metrics page, you'll find your metrics token and URL, allowing you to request the warp10 database with Quantum (it's a (WarpScript™ IDE).

You can open Quantum within Metrics, and click on "access logs" located in the "Explore your data" section. Here's an example:

[
  '<TOKEN>'
  'accessLogs'
  { 'app_id' '<APP_ID>' }
  NOW 5 s
] FETCH

As access logs are still quite complex to retrieve that way, we are still working on a better way to make it accessible to you. Stay tuned for the next iterations!

What's new?

Multiline support

Edits then update

Input validation

Small UX improvements

• The design of the focus ring has been improved. It should be more visible for any keyboard user that needs it.

• We're introducing a skeleton screen when data is loading:

• We use a loader animation when data is updating:

• For add-ons, we reuse the same component but in read-only mode:

• For add-ons, you still have the expert mode so you can copy/paste easily from it:

What's next?

It's already been a couple of weeks since we introduced you to our revamped console. And as we wrote at that time, we are not stopping there. We are always working on new stuff to make your life easier.

Today we introduce you to our new filtering system built with love by Arnaud and Hubert. As you might have seen already we have merged apps and add-ons. So in the same list you end up having apps that uses different runtime and build tools as well as various add-ons. We are now allowing you to filter this list based on these specifics.

If you type is:redis in the filter field you will only see your Redis add-ons. If you type is:node you will only see nodejs applications. It's that simple. And of course you can combine these filters or use them with the usual name search:

• is:java is:jar
• is:java is:sbt
• is:java ACME
• is:java prod

Now you might be wondering, how does this work? What can I use as filter? For add-ons we use their slug. Here's the list:

mysql
postgresql
redis
cellar
fs-bucket
config-provider
mongodb

For applications it's more subtle. You can use their type or their variant slug. What is a variant you ask? Well it's something we use internally to put different sort of automation secret sauce on our VM images. Take for instance the node image type. It has two variants. One is node which is pretty much the default behavior for node.js applications. The other is meteor, used for Meteor.js applications, which installs Meteor and runs specific build and run tasks. If you look at the java type you will see we have a number of variants representing the different ways to deploy JVM code with different build tools.

Type            Variant Name            Variant Slug
--------------------------------------------------------
python          Python                  python
haskell         Haskell                 haskell
php             PHP                     php
php             Static                  static-apache
ruby            Ruby                    ruby
python-gunicorn Python Gunicorn         python-gunicorn
go              Go                      go
java            Java + Play! 1          play1
java            Java or Scala + Play! 2 play2
java            Java or Groovy + Gradle gradle
java            Java + JAR              jar
java            Java + Maven            maven
java            Scala + SBT             sbt
java            Java + WAR              war
node            Meteor.js               meteor
node            Node                    node
docker          Docker                  docker
rust            Rust                    rust
erlang          Elixir                  elixir

For future releases, we're also thinking about filters like is:running, is:stopped, sort:status, sort:type. We might also add Tags which are already available in our API. If you would like to filter this list based on other characteristic please let us know in the comments below :)

First, the new status icons

A new filter field

Then, the new app overview

• We are now displaying current status, with some additional details on it (git commit, etc.)
• The runtime of the app is now clearly displayed with an icon

• The instances list (reusing the new status icon) is visually optimized
• The scalability settings (read-only) are now shown
• And we've added info about the two last deployments

Oooh, I log you so 🎶

Let's wrap-up

What about some moar

• Global create button on top (new apps/addons panel)
• Variant/runtime icon next to the app (new apps/addons panel)
• Refreshed icons/shape for app creation
• Refreshed icons/shape for addon creation

A future moving forward

Friends don't let Friends SSH on production

• A user gets on the machine to debug something, fixes it on their code, pushes and redeploys.
• A user gets on the machine to debug something, fixes it on the machine and calls it a day.

How does it work?

With SSH

With Clever Tools

clever ssh
> Opening an ssh shell
> bas@67fbf787-3518-47bb-abd9-2c2575844edd ~ $ 

clever ssh
> 1) Sleepy Ponita - Instance 0 - UP (11281f38-31ff-43a7-8595-a2d82630c32b)
> 2) Tense Caterpie - Instance 1 - UP (b10d19d9-5238-408b-b038-3e32c7a301c2)
> Your choice: 1
> Opening an ssh shell
> bas@11281f38-31ff-43a7-8595-a2d82630c32b ~ $

What's a Webhook though?

A webhook in web development is a method of augmenting or altering the behavior of a web page, or web application, with custom callbacks. These callbacks may be maintained, modified, and managed by third-party users and developers who may not necessarily be affiliated with the originating website or application.

Neat! How do you do that?

Coming soon

Hello from Team Clever Cloud!

We are quite excited to release a major new version of our Dashboard.
It includes a lot of bug fixes as well as a few additions. We've included automatics payments, a design refresh, an activity feed, a better log management. And a nice GitHub integration too.

So today we’re launching these new features, and I'd like to detail some of them:

GitHub

As you may have noticed, the GitHub button showed up recently on the Clever Cloud website and our login & signup forms.
This feature aims to simplify the login & signup process, but also to bring your GitHub repositories to Clever Cloud.

Automatic Payments

We used to base our billing on an account balance. While running, apps consume those credits. Since the begining, our users had to fill it with money manually. Now, a monthly amount can be automatically credited each month.

And to deal with scalable consumption, a threshold can be set up too. How does it work?

The billing threshold is initially set at a certain amount. Each time your account hits its threshold before the 30-day billing cycle has ended, your credit card is debited of the amount you've set up. See an example of recurring payment configuration below:

New UI

We teamed up with our most active users to create a better and clearer UI. We’re bringing to the dashboard simpler components and a more contrasted layout. You can even add an avatar for your profile or organization.

Activity Feed

The activity feed lets you track your apps' activity. When you open the activity tab, you will see each deploy and un-deploy event, with the following data:

• the date
• the type (deploy, undeploy)
• the reason of deploy (scaling, monitoring etc)
• and the commit ID

Better Logs Management

It's now easier to deal with logs: the start time of each instance is now displayed next to its id. This allows an easier bug tracking on deploy processes. It comes with a nicer and more helpful UI.

If you want to give this a whirl, head up to the console!

French version below

Up to now, during a git deployment, it wasn’t possible to keep all your updated content (and additionnal logs) for the next deployment. Now, thanks to the FS buckets all the content is kept and can be shared by all of the instances.

Available directly by FTP, these buckets can be mounted in the application’s folder during the deployment.

Creating a bucket is really simple. First, select the appropriate organisation in the headbar. Then click on the “Services” tab in your organisation and then choose “FS buckets”. You will receive the new bucket’s credentials by email a few minutes later.

It’s important to update your applications to use the buckets in the file clevercloud/buckets.json which is into the folder “clevercloud” at the root of your application.

For more details go to the documentation.

Version française

Jusqu’ici, lors d’un déploiement git, il n’était pas possible de conserver tout votre contenu mis à jour (ainsi que les logs supplémentaires) pour un déploiement ultérieur. Maintenant, grâce aux FS buckets le contenu est donc conservé mais peut aussi être partagé entre les instances.

Accessibles directement par FTP, ces buckets sont montables dans le dossier de l’application lors du déploiement.

Créer un bucket est très simple. Commencez par choisir l’organisation qui vous intéresse dans la barre de navigation de la console. Cliquez sur le bouton “Services” et choisissez désormais “FS buckets”. Une confirmation vous est ensuite envoyée par mail.

Il est important de mettre à jour vos applications pour utiliser les buckets depuis le fichier clevercloud/buckets.json qui se trouve dans le dossier “clevercloud”, à la racine de votre application.

Pour plus de détails, rendez-vous sur la documentation.