Skip to content

Configuration Guide

This document describes all configuration options available in the DSTA project and how to configure different environments.

Overview

DSTA uses environment variables for configuration management, providing: - Centralized configuration through dsta.config.Config class - Type-safe access to configuration values - Automatic validation of required settings - Support for multiple environments (development, staging, production) - Sensible defaults for development

Quick Start

Development Environment

For local development, the application works with default values. No configuration is required to get started.

Production Environment

For production, create a .env file or set environment variables:

# Environment
ENVIRONMENT=production
DEBUG=False
SECRET_KEY=your-secret-key-here

# Database
DB_HOST=your-db-host
DB_NAME=dsta_prod
DB_USER=dsta_prod
DB_PASSWORD=secure-password

# Redis
REDIS_HOST=your-redis-host
REDIS_PASSWORD=secure-redis-password

# Exchange APIs
BINANCE_API_KEY=your-binance-api-key
BINANCE_SECRET_KEY=your-binance-secret-key

Configuration Options

Environment Settings

ENVIRONMENT

  • Type: String
  • Default: development
  • Options: development, dev, staging, production, prod
  • Description: Determines which environment the application is running in. Affects default log levels and validation rules.

DEBUG

  • Type: Boolean
  • Default: True in development, False in production
  • Description: Enables Django debug mode. Must be False in production.

Django Settings

SECRET_KEY

  • Type: String
  • Default: Default development key
  • Required: Yes (must be changed in production)
  • Description: Django secret key for cryptographic signing. Must be unique and kept secret in production.

ALLOWED_HOSTS

  • Type: Comma-separated list
  • Default: *
  • Required: Yes (cannot be * in production)
  • Description: List of allowed host/domain names for the application.
  • Example: example.com,api.example.com

Database Configuration

DB_ENGINE

  • Type: String
  • Default: django.db.backends.postgresql
  • Description: Django database engine.

DB_NAME

  • Type: String
  • Default: dsta
  • Description: Database name.

DB_USER

  • Type: String
  • Default: dsta
  • Description: Database user.

DB_PASSWORD

  • Type: String
  • Default: dsta@20211
  • Required: Yes (should be changed in production)
  • Description: Database password.

DB_HOST

  • Type: String
  • Default: database
  • Description: Database host address.

DB_PORT

  • Type: Integer
  • Default: 5432
  • Description: Database port.

Redis Configuration

REDIS_HOST

  • Type: String
  • Default: redis
  • Description: Redis server host address.

REDIS_PORT

  • Type: Integer
  • Default: 6379
  • Description: Redis server port.

REDIS_DB

  • Type: Integer
  • Default: 0
  • Description: Redis database number (0-15).

REDIS_PASSWORD

  • Type: String
  • Default: None
  • Description: Redis password (if authentication is enabled).

Celery Configuration

CELERY_BROKER_URL

  • Type: String
  • Default: redis://redis:6379/0
  • Description: Celery broker URL.

CELERY_RESULT_BACKEND

  • Type: String
  • Default: redis://redis:6379/0
  • Description: Celery result backend URL.

Exchange API Configuration

BINANCE_API_KEY

  • Type: String
  • Default: None
  • Required: No (but needed for trading features)
  • Description: Binance API key for trading operations.

BINANCE_SECRET_KEY

  • Type: String
  • Default: None
  • Required: No (but needed for trading features)
  • Description: Binance API secret key.

Logging Configuration

LOG_LEVEL

  • Type: String
  • Default: DEBUG (dev), INFO (staging), WARNING (prod)
  • Options: DEBUG, INFO, WARNING, ERROR, CRITICAL
  • Description: Minimum log level to record.

LOG_DIR

  • Type: String
  • Default: logs
  • Description: Directory for log files.

LOG_JSON

  • Type: Boolean
  • Default: False (dev), True (production)
  • Description: Whether to use JSON formatting for logs.

Telegram Bot Configuration

TELEGRAM_BOT_TOKEN

  • Type: String
  • Default: None
  • Description: Telegram bot token for notifications.

TELEGRAM_CHAT_ID

  • Type: String
  • Default: None
  • Description: Telegram chat ID for sending notifications.

Application Settings

DATA_DIR

  • Type: String
  • Default: data
  • Description: Directory for storing data files.

Using Configuration in Code

Basic Usage

from dsta.config import get_config

# Get configuration instance
config = get_config()

# Access configuration values
print(config.ENVIRONMENT)
print(config.DEBUG)
print(config.DB_HOST)

In Django Views

from dsta.config import get_config

def my_view(request):
    config = get_config()

    if config.BINANCE_API_KEY:
        # API is configured
        pass
    else:
        # API not configured
        pass

Getting Database Config

from dsta.config import get_config

config = get_config()
db_config = config.get_database_config()
# Returns: {'ENGINE': '...', 'NAME': '...', ...}

Getting Redis URL

from dsta.config import get_config

config = get_config()
redis_url = config.get_redis_url()
# Returns: 'redis://host:port/db' or with password

Configuration Dictionary

from dsta.config import get_config

config = get_config()
config_dict = config.to_dict()
# Returns dictionary with non-sensitive config values

Environment-Specific Configuration

Development

Development uses sensible defaults that work out of the box: - DEBUG mode enabled - Detailed logging (DEBUG level) - Plain text log formatting - Permissive ALLOWED_HOSTS

Staging

Staging environment for testing: - DEBUG mode disabled - INFO level logging - Should use production-like settings - Separate database and credentials

Production

Production requires: - Custom SECRET_KEY (validation enforced) - DEBUG disabled (validation enforced) - Specific ALLOWED_HOSTS (validation enforced) - JSON log formatting - WARNING level logging - Secure database credentials - SSL/TLS for external connections

Validation

The configuration system performs automatic validation:

  1. Production Checks: In production environment:
  2. SECRET_KEY must be changed from default
  3. DEBUG must be False

  4. ALLOWED_HOSTS cannot be '*'

  5. Type Validation:

  6. Integer values are validated and converted

  7. Boolean values are validated and converted

  8. Log Level Validation:

  9. LOG_LEVEL must be valid option

Handling Validation Errors

from dsta.config import get_config, ConfigError

try:
    config = get_config()
except ConfigError as e:
    print(f"Configuration error: {e}")
    # Handle error appropriately

Reloading Configuration

Configuration is cached as a singleton. To reload:

from dsta.config import reload_config

# Reload configuration from environment
config = reload_config()

Best Practices

  1. Never commit secrets: Keep .env files out of version control
  2. Use different values per environment: Don't reuse production credentials in dev/staging
  3. Validate early: Start the application and check logs for configuration issues
  4. Document custom variables: Add any custom configuration to this document
  5. Use type hints: The Config class provides type-safe access
  6. Test configuration: Verify configuration in staging before production deployment

Environment Variable Loading

Order of Precedence

  1. System environment variables (highest priority)
  2. .env file in project root
  3. Default values in Config class (lowest priority)

Using .env Files

Create a .env file in the project root:

# .env
ENVIRONMENT=staging
DEBUG=False
DB_HOST=staging-db.example.com
REDIS_HOST=staging-redis.example.com

The application will automatically load these values on startup.

Docker Configuration

When using Docker, pass environment variables via docker-compose:

services:
  api:
    environment:
      - ENVIRONMENT=production
      - DB_HOST=postgres
      - REDIS_HOST=redis
    env_file:
      - .env.prod

Troubleshooting

Configuration not loading

  1. Check environment variable names (case-sensitive)
  2. Verify .env file location (must be in project root)
  3. Check for typos in variable names
  4. Review application logs for configuration errors

Validation failures

  1. Review validation error message
  2. Check that production values are set correctly
  3. Verify SECRET_KEY is changed from default
  4. Ensure DEBUG is False in production

Missing configuration

  1. Check default values in dsta/config.py
  2. Verify environment variable is exported
  3. Confirm .env file is readable
  4. Review application logs

Security Considerations

  1. SECRET_KEY: Must be unique, long (50+ characters), and random
  2. Database passwords: Use strong passwords, rotate regularly
  3. API keys: Keep secret, never log or expose in responses
  4. Environment variables: Restrict access to production environment variables
  5. Logs: Ensure logs don't contain sensitive information

Migration from Old Configuration

If migrating from hardcoded settings:

  1. Identify all hardcoded configuration values
  2. Add corresponding environment variables
  3. Test in development environment
  4. Update deployment scripts
  5. Deploy to staging and verify
  6. Deploy to production

Support

For configuration issues: 1. Check this documentation 2. Review application logs 3. Verify environment variables 4. Check default values in source code 5. Open an issue on GitHub if problem persists