Skip to main content

How Tower works

This is a high-level, technical description of how Tower works. It brings together lots of concepts that are important for writing and maintainting Tower apps, as well as helps you understand how Tower behaves in production.

Defining an app​

An app is composed of your Python code, a requirements.txt file that describes the dependencies you use in your Python code, any data you might want to package with it, and a Towerfile that tells Tower how to use all of it. Tower can run any Python. There's no integration: Just hand us Python, and we'll run it.

Knowing what to run​

Tower uses the Towerfile in your app's root directory to figure out how and what, exactly, to run for your app. The Towerfile contains all the information about what source code to run, what dependencies to download, and what file is your entrypoint.

See the Towerfile reference for more information.

Example Towerfile​

[app]
name = "my-app"
script = "./pipeline.py"
source = [
    "./**/*.py",
    "./*.py",
    "./requirements.txt"
]

Using your Towerfile, Tower creates a package that it encrypts and saves for execution later.

Deploying apps​

Applications are deployed to Tower using the CLI. When you run tower deploy, Tower uses your Towerfile to build a package that's shipped to Tower and encrypted for storage.

info

Because your Tower packages are encrypted, Tower doesn't know what's inside the package. Tower can not read or get access to your code.

Configuring apps​

There are a number of features available in Tower to parameterize or configure apps at runtime, not to mention the fact that you can ship configuration data with the app in your Towerfile as described above!

Secrets​

The primary way to share things like database credentials, cloud provider keys, or any other configuration with a Tower app is with secrets. Secrets are keys and values, available via the tower secrets commands in the CLI, that are shared with the app as environment variables at runtime.

info

Secrets in Tower are encrypted end-to-end using AES-256 with unique encryption keys for each account. The only environment in which they're decrypted is at runtime in the Tower runner. Tower can not see or read your secret data.

The Tower runtime environment​

Tower uses a runner model to run your app. The runner knows how to talk to Tower to get the latest version of the code and any configuration, it knows how to decrypt your data, and it uses a special sandboxed version of Python to securely run the application.

The Tower runner​

The backbone of the Tower runtime environment is the Tower runner. The runner is a small program that comes online and talks to Tower, looking for app jobs to run. When there's an app to run, it downloads the latest version of the app, executes it, and cleans up after the app when it's done.