Container Configuration

Modify how your container is deployed, run, or scaled. Cycle's commitment to simplicity does not mean sacrificing customizability. Nearly every aspect of how a container is run, from it's deployment tags to resource limits, are configurable.

Accessing Container Config

To get to the container config, follow these steps:

  1. Click the Environments tab on the navigation menu to the left.
  2. Select the environment the container instance you want to access is in.
  3. Click the Containers tab under the environment name.
  4. Select the container from the list.
  5. Click the Config tab under the container name.

Use the tabs on the left to navigate to different sections of the config. Feel free to modify multiple config settings between tabs before clicking "Save & Restart" Some sections of the config may be disabled, meaning none of the settings underneath will take effect. To enable it, make sure the toggle in the top right of the form is set to "Enabled"

Changing the configuration of a running container will cause it to restart!



The hostname is how other containers identify this container within the network.

Updating the hostname will restart all instances of the container. Discovery will automatically be informed of the new name and will not need to be restarted.

Public Network

There are three types of network privilege a container can have:

  • Disabled - Public internet access is completely disabled for this container. It may only communicate with other containers within the same environment. This is ideal for sensitive things, such as databases.
  • Egress Only - The container may initiate connections over the internet, but all incoming connections will be blocked. This is ideal for things that require fetching data from the web, but do not need to respond to inbound requests, such as web scrapers.
  • Enabled - The container is able to both start and accept connections over the internet. This is a must for websites, APIs, and other services where clients may not be known ahead of time.

Port Mappings

Only the ports specified are exposed on the host (for that container's specific IP). The format is [container]:[host], meaning Cycle will expose route traffic to the host port to the container, and map it to the internally to the container port (the one your application will read). For example, 3000:80 will accept connections on port 80, but your application will serve over port 3000.

Name Servers

Override default name servers for your container by setting them here. All DNS lookups will go through the specified IP addresses rather than Google's (


The runtime configuration specifies the how a container starts, information it has access to, and permissions it has on the host. It needs to be enabled for the settings underneath to have an effect.

Environment Variables

Configure your containers' environment variables.

  • Add a environment variable to the environment variable fields.
  • Use the Add Variable button.
  • Repeat the last two steps until you've added all the environment variables for this container.
  • Remember to Save Config.

There are Cycle specific environment variables injected into each container. You can find the full list here. Some of these will be instance specific, such as CYCLE_INSTANCE_IPV6_SUBNET.

Environment variables defined on the image cannot be removed. Cycle interprets these as critical to the way your program works. However, their values can be changed, which may be useful for things such as specific development-only settings. You are free to create and remove environment variables outside of those defined on the image.


  • Path - Set an override to the default command run when the container starts. May be useful if you have a custom debug command you wish to run.
  • Args - Any arguments you wish to pass into the overidden path.


These settings define exactly what privileges the container has on the host.

Changing these settings can open you up to security vulnerabilities. Do so at your own risk.
  • Namespaces - Namespaces define what is isolated in the container, and what is used on the host. The fewer namespaces a container has, the less secure it becomes. By default, a container has all namespaces enabled. At the least, they must have the MOUNT namespace. See here for detailed descriptions of the available namespaces.
  • Privileged Capabilities - You can granularly assign specific kernel-level capabilities to a container for extra functionality. These can lead to interesting use cases, for example adding the CAP_NET_RAW capability, and building a containerized network monitoring dashboard. See here for detailed descriptions of the available kernel capabilities.
  • Run as Fully Privileged - This is by far the most dangerous option available to you. This gives the container full permissions on the host, treating it as a root process.There is almost no reason to do this, and you will most likely break something. If you feel there is a reason to do this, reach out to our support team. We'll help you find a better way.


Feature Alert

At the moment, Cycle's scaling options are purposefully limited. We are in the process of adding more granular options. For more information on how you can quickly change the number of container instances deployed check out this section.

Scaling refers to how many and where container instances are started. There are many different ways applications can be scaled, including geographic and load based scaling. Cycle's current scaling solution, while basic, is the foundation to more complex and powerful scaling we will be implementing over time.

Select the minimum and maximum number of instances, and Cycle will start that many instances, balanced across all servers matching your deployment tags.


If you're coming from the VM world, you are probably used to resource allocations, where you set aside a chunk of RAM, storage, CPU time, etc that can only be utilized by that VM. In the container world, we set limits.

Shares are the units we use to describe compute usage. A full share is 10 and equates to a single virtualized core or thread. To calculate shares available, multiply the amount of virtual cores or the amount of threads you have available on the infrastructure by 10.

By default, Cycle will pre-allocate each instance with a default of 2 shares. That means that when you create an environment Cycle will allocate shares to your service containers as well. If you go over the total shares available on your infrastructure, Cycle will no longer allow you to deploy instances to that infrastructure.

VPN containers are never counted during pre-allocation.


Both the limit and reserve of the CPU can be set. This setting directly relates to the amount of shares available on the host. Setting a limit of 6 would translate to limiting the instance to 60% of a single core or thread. Setting a reserve of 2 would reserve 1/5th of the total available compute time on a single core for each instance.

In addition to the limit and reserve, Cycle also supports CPU pinning. Setting this option will force your container to run only on the specified cores. This allows you to control which cores your instances have access to.


RAM is very straightforward - limits and reserves are set in KB, MB, GB etc. In addition, you can define the swappiness of your container's RAM usage. Swappiness defines how much (and how often) your container will copy RAM contents to swap. This parameter's default value is "60" and it can take anything from "0" to "100". The higher the value of the swappiness parameter, the more aggressively your container will swap.


This section refers to how your containers are deployed.

Initial Instances

The initial number of instances are set on container create, and are here for reference. To adjust the current number of instances, please refer to the scaling section.

Deployment Tags

In short, deployment tags give you the power to match container instances to servers that meet the criteria.

If left blank, Cycle will deploy instances to any available servers until the 'Initial Instances' quota has been met.

Integrations - TLS/SSL Certificates

By utilizing Let's Encrypt, Cycle can take the pain of remembering to renew your certificates off your shoulders. Certificates are renewed every 90 days.

In order to enable automatic TLS/SSL certificate management, you must first set a domain to the container. Then, check the "Enable Automated TLS/SSL" box. By default, Cycle will install the generated certificates to/var/run/cycle/tls. Depending on how your application is set up, you may wish to change this. Do so by entering the full path into the "Certificate Installation Path" field.


Cycle can be configured to auto-restart your container if it detects the process has died. You may also specify who to email on restart, and if Cycle should call out to a webhook.

The max restarts field refers to how many times Cycle will attempt to "resuscitate" your container, and the delay is how many seconds between attempts the platform will wait. By default Cycle will attempt to restart your container 15 times, after this point manual intervention is necessary.

Need Help?

If you've got questions about the platform or need some help getting started, our team is more than happy to assist. Whether you're new to containers or just new to Cycle, reach out to us via livechat by clicking the blue circle in the bottom right corner. Join our Slack channel, and get help from the dev team or other members of the community, and check out our Roadmap to see what's planned for the future!