Implemented Features

This is a list of notable features that have currently been implemented.

  • Not coupled to Source Control Management (SCM) software.

    • A site is deployed via a site configuration file.

    • Each site configuration defines a 'release' tar.gz file which contains the source code for the site. The release tar.gz file can be referenced locally via absolute file path or downloaded from a URL.

    • Deployments will effectively skip already deployed sites based on the version string of the site.

  • Supported language handlers for services

    • Python WSGI or ASGI managed by Gunicorn

    • Python workers

    • Chill with dynamic or static deployment

    • Immutable services with resources stored on S3 object storage or disk

    • podman to run containers

      • Image is loaded from the artifact tar.gz

      • Networking for containers is limited and only allows ingress. No egress to other services on the box from a container.

    • Compiled binaries

    • Scheduling commands with crontab

  • The build and install of Python service dependencies only use local dependencies referenced by a requirements.txt file in the versioned artifact. The pip install --no-index …​ command is used when installing Python services on the chillbox server for better security.

  • Each site can use and configure a secure Redict instance that is only available on a unix socket. Only the site’s services and workers can access it.

  • Website services run on Alpine Linux and don’t use systemd

  • Support deploying to either Alpine Linux or Debian

    • With Alpine Linux; OpenRC and s6 is used instead of systemd to align with the goal of using less software. Also see A word about systemd from the author of s6.

    • Debian is supported because most cloud hosts don’t offer Alpine Linux as a Linux distribution.

    • Doing a chroot install of Alpine Linux on an existing deployed server running Debian is non-trivial in my opinion, and creating a custom Alpine Linux image for a cloud host has some drawbacks.

  • Shell scripts are POSIX compliant

  • Website configuration is in either JSON or TOML.

  • No remote build pipeline, all builds happen on the local host machine

    • Secrets are encrypted and stored securely on the host machine

    • Secrets used on the chillbox server are encrypted to a public key, the private key is generated on the chillbox server and never stored elsewhere.

  • Start long running worker processes defined by the site. Support using RQ, ARQ, or a custom run command. Allow running multiple copies of them.

Other Ideas for New Features

These ideas might be a bit outside of the goals and are not part of any immediate use case that I currently have. These are the things I would be tempted to implement.

  • Deploy multiple chillbox servers for high availability

  • Deploy multiple chillbox servers to different regions and improve response time with GeoDNS

  • Option to use a managed DNS provider that has GeoDNS

  • Support other language handlers for services

  • Batching large jobs by spinning up temporary resources

  • Support for running OpenFaaS functions with faasd

  • Monitoring and ability to easily view logs without being on the server

  • Locking down a server and making it immutable, disabling SSH, auto shutdown if a process is executed that is not in the accept list.

Out of Scope Features

This project may not be a good fit for someone expecting a fully finished and battle tested solution.

  • Use of cloud hosting provider services that have expensive bandwidth costs (free tiers and such are not considered)

    • AWS CloudFront - 0.085 per 1GB transfer out

    • AWS EC2 and other compute - 0.09 per 1GB?

    • AWS S3 Buckets - 0.09 per 1GB?

  • Auto scaling resources

  • Deployments triggered by version control (GitOps)

  • Dependency on any specific solutions provided by a single cloud host (vendor lock-in)

  • No virtual machines like Firecracker

Alternatives

I suggest looking at other alternative solutions if Chillbox and the shell scripts involved don’t meet your needs. This project is being developed by myself (Jake Hickenlooper) and I may break existing functionality with any updates.

I’m aware of these other projects that start with "K":

  • Kubernetes, also known as K8s, is an open source system for automating deployment, scaling, and management of containerized applications.

  • K3s - Lightweight Kubernetes

  • k0s - The Zero Friction Kubernetes

  • Kamal - Deploy web apps anywhere

Copyright (C) 2024 Jake Hickenlooper
https://git.sr.ht/~jkenlooper/chillbox