Skip to main content

Applications Overview

Applications are the core workloads you deploy and run on the Thevenin platform. This guide explains the fundamental concepts and how applications work within environments.

What are Applications?​

In Thevenin, an application is a containerized workload deployed within an environment. Applications run from Docker images and can be configured with:

  • Container images
  • Resource allocations (CPU and memory)
  • Environment variables
  • Persistent volumes
  • Port mappings
  • Configuration files

Key Concepts​

Container Images​

Thevenin applications run from container images. You specify:

  • Image Name: The Docker Hub image (e.g., nginx, postgres, node)
  • Tag: The specific version (e.g., latest, 14, 18-alpine)

Format: image:tag

Examples:

  • nginx:latest - Latest NGINX web server
  • postgres:14 - PostgreSQL version 14
  • redis:alpine - Redis with Alpine Linux
  • node:18-alpine - Node.js 18 on Alpine

Resource Management​

Each application is allocated specific resources within an environment:

CPU Allocation

  • Measured in cores or millicores
  • Example: 0.5 cores, 1 core, 2 cores
  • Limits how much processing power the application can use

Memory Allocation

  • Measured in MB or GB
  • Example: 512 MB, 1 GB, 2 GB
  • Prevents applications from using excessive memory

Environments and Applications​

Applications always run within environments:

  1. Environment First: Create an environment before deploying applications
  2. Isolated Resources: Each environment has its own resource pool
  3. Multiple Applications: An environment can host multiple applications

Example Workflow:

1. Create "Production" environment (4 cores, 8 GB memory)
2. Deploy "web-app" application (1 core, 1 GB)
3. Deploy "api-service" application (1 core, 1 GB)
4. Deploy "redis-cache" application (0.5 cores, 512 MB)

Application Components​

Ports and Networking​

Applications can expose ports for network communication:

Container Port: The port your application listens on inside the container

  • Example: Web servers typically use port 80 or 8080
  • Example: Databases use specific ports (5432 for PostgreSQL, 3306 for MySQL)

Protocol: HTTP, GRPC,TCP or UDP

  • Use HTTP or GRPC over TCP to get Application Layer features. Examples: web services, APIs
  • Use TCP if your application doesn't support HTTP or GRPC. Examples Databases, SSH, SFTP, Brokers, Caches
  • Some real-time services use UDP . Examples: game servers. live video streaming. DNS, Voice over IP (VoIP).
info

Exposing UDP plublicly is not yet supported Exposing Layer 4 TCP plublicly is a feature still in progress Exposing HTTP and GRPC plublicly is fully supported and done on port 443

Environment Variables​

Configure your application using variable set:

DATABASE_URL=postgresql://host:5432/db
NODE_ENV=production
PORT=3000

Variable Sets are reusable collections of variables. Can be shared across multiple applications or deleted with the application. See Variable Sets

Persistent Storage​

Applications can use volumes for data that persists beyond the container lifecycle:

Use Cases:

  • Database data storage
  • User uploaded files
  • Application logs
  • Configuration that changes at runtime

See Volumes for more information.

Application Files​

Add custom files to your application:

Common Uses:

  • Configuration files (config.yaml, settings.json)
  • SSL certificates
  • Application-specific scripts
  • Static assets

Common Application Patterns​

Thevenin can be used to setup different Applications Patterns, which are include but are not limited to:

Stateless Applications​

Applications that don't store data locally:

Examples:

  • Web frontends
  • API services
  • Proxies and load balancers

Characteristics:

  • No persistent volumes needed
  • Can be restarted without data loss

Stateful Applications​

Applications that manage persistent data:

Examples:

  • Databases (PostgreSQL, MySQL, MongoDB)
  • Message queues (RabbitMQ, Redis)
  • File storage services

Characteristics:

  • Require persistent volumes
  • Restart requires data preservation

Worker Applications​

Background processing applications:

Examples:

  • Job queues
  • Data processing pipelines
  • Scheduled tasks

Characteristics:

  • May not expose ports
  • Often use message queues
  • Run continuously or on schedules

Best Practices​

Image Selection​

✅ Do:

  • Use official images when possible (nginx, postgres, redis)
  • Specify exact version tags (14 not latest)
  • Use Alpine variants for smaller sizes (18-alpine)
  • Test images in development before production

❌ Don't:

  • Use :latest tag in production
  • Use untrusted or unmaintained images

Resource Planning​

✅ Do:

  • Start with minimal resources
  • Monitor actual usage

❌ Don't:

  • Over-provision unnecessarily
  • Under-provision critical services

Configuration Management​

✅ Do:

  • Use environment variables for configuration
  • Leverage variable sets for reusable config
  • Keep secrets in variable sets, not code
  • Document required variables

❌ Don't:

  • Hardcode configuration in images
  • Use same config for all environments
  • Leave variables undocumented
  • Commit secrets to version control

Security​

✅ Do:

  • Use specific, tested image versions
  • Keep images up to date

❌ Don't:

  • Run containers as root if avoidable
  • Expose unnecessary ports
  • Use default passwords

Next Steps​

Now that you understand applications, learn how to:

Getting Help​

If you encounter issues:

  1. Check the Creating Applications troubleshooting section
  2. Review application logs in the dashboard
  3. Verify resource allocations are sufficient
  4. Contact support through the dashboard