metadata: title: Internet mode categories: “Production”: order: 2 content: |

## Introduction

### Why a separate  Internet mode

ShimmerCat has two top modes, "devlove", and "Internet".
Devlove mode is always available, and Internet mode is available
by [purchasing the upgrade]().

The mode is a mandatory argument of the command line, and
it allows the user to state his intention when running the
Devlove mode should support developers while
they code and test their applications, and internet mode should make easy
and secure to deploy websites on the Internet.

$ shimmercat internet -h
A master mode for monitoring workers and running in the Internet

The two use cases have sometimes contradictory goals.
When an application is being developed, developers need to see as much
information as possible, even when that information is presented in
the webpage being served.
Think about pages with status code 404 and 500 reported from Django
for example.
However, the same information can prove to be too sensitive for
public eyes, which are likely to access the site through Internet

In this documentation page, we detail the features of Internet
mode in ShimmerCat.

### Breaking with tradition

Unix has a long tradition of running services on the Internet.
For that purpose, the most sophisticated and used variant of Unix
is Linux, whose latest editions come with some fantastical features.
These modern features often do things different, and we think that's
for the better.

As a rule, we have embraced the new ways of doing things,
and in this article we explain what we mean.

[Should we stick more to tradition?](

## (No) Fork gymnastics

### Internet mode is a simple worker manager

When `shimmercat internet` is run, the first process creates
a few  worker children, and an instance of
Redis (bound to a unix socket).
Children use the Redis instance to exchange information and
to [send log messages](/en/docs/1.5/logging/) to the parent
process or any other logs agent.

Every few minutes, workers undergo [apoptosis](/en/msg/current-version/M40022/) and
are re-spawn by the original process.
The time interval for the apoptosis is random and always greater than
15 minutes, so there should
always be a few worker processes alive and handling requests.

Note that each worker can handle an unlimited number of
concurrent sessions and requests, the only limits being CPU, RAM and I/O
We launch multiple workers in Internet mode to profit better from
multi-core architectures and to have increased redundancy.

### No fork gymnastics to become a daemon

Classical internet servers do a lot of tricks to become daemons.
But modern system supervisors like SystemD, Upstart and Supervisord can do
that on behalf of the service.
We think that modern supervisors do an outstanding work, and therefore do not support
process daemonization from inside ShimmerCat.

We however check if stdout is a tty, and if it is not, suppress the ANSI
escape sequences for colors.

### No fork gymnastics to share a port

We just set [SO_REUSEPORT]( in all ports we
bind to.

### No fork gymnastics to drop privileges

We do not drop privileges.

ShimmerCat can run as an unprivileged user, just by indicating such user
to the supervisor (Systemd, Supervisord, Upstart, etc).
To  bind directly to ports 443 or 80 without being root, you can use `setcap`:

setcap cap_net_bind_service=+ep `which shimmercat`

Most of ShimmerCat is written in Haskell, and that  mitigates
the risk of privilege escalation attacks based on buffer overflow.

To  strengthen the security of your setup,
we recommend using either containers (e.g. Docker) or any of
Cgrups, AppArmor or SELinux.

[Let us know what do you think](

## Redirects from HTTP at port 80 to HTTPS at port 443

ShimmerCat doesn't serve sites over plain HTTP.
But there is a common use case for still listening to plain HTTP requests,
namely redirecting users from `` to ``.

To enable listening for plain HTTP requests and doing  redirects on them,
simply use the the `-t` option    followed by a local network address to bind to,
or a wildcard address.
E.g: `shimmercat internet -t`

For enhanced security, connections on the HTTP to HTTPS redirects port are shutdown
as soon as ShimmerCat finishes sending the redirect response, or after three seconds,
whatever happens first.

## One certificate per ShimmerCat's instance

You can run different virtual domains simultaneously with ShimmerCat, the only
restriction being that they use a common certificate.

[Which questions we didn't answer?](