Project Definition

The Project class in NoBS is the central configuration object for defining your entire application stack, from web services and background workers to infrastructure dependencies and deployment requirements. Think of it as a powerful, developer, friendly alternative to combining Docker Compose, Terraform, and CI/CD configuration into a single, intuitive Python definition.

Instead of juggling multiple YAML files across different tools, NoBS lets you describe everything your project needs, code, services, secrets, compute resources, domains, and dependencies, in one coherent, type-safe Python object.

What Is a Project?

At its core, a Project describes a complete system: the services it runs, how they communicate, what secrets they need, and what infrastructure must be provisioned. It’s conceptually similar to a docker-compose.yml file, but goes much further by also handling:

• Automatic provisioning of cloud resources (like databases or buckets)
• Secure secret management
• Domain configuration and TLS
• Resource constraints (CPU, RAM)
• Background jobs and event-driven workers All of this is defined in pure Python, making it easy to refactor, test, and share logic across environments.

A Simple Example: FastAPI App

Here's a minimal Project that deploys a FastAPI application with HTTPS and Slack notifications enabled via secrets:

from nobs.models import Project, FastAPIApp
from nobs.secrets import SlackWebhook

project = Project(
    name="fastapi-project",
    server=FastAPIApp(
        app,  # Your FastAPI app instance
        secrets=[SlackWebhook],
        domain_names=[
            "cloud.aligned.codes",
            "www.cloud.aligned.codes",
        ],
    ),
)

In this example:

• NoBS automatically detects that you're running a web server and assigns it a public endpoint.
• The SlackWebhook secret is securely injected at deploy time.
• TLS is automatically configured for the listed domains.
• No additional configuration files or scripts are needed, this single definition is enough to deploy the full service.

A More Complex Example: MLOps Stack

Now consider an MLOps project that includes an MLflow tracking server, a Streamlit dashboard, S3-backed storage, and a background worker for training models:

from nobs.models import Project, MlflowServer, StreamlitApp, Worker, Compute
from nobs.secrets import MlflowConfig, S3StorageConfig
from src.pokemon_app import main
from src.pokemon import load_all_data, train_model

# Define a background worker for async tasks like model training
background = Worker("background")

project = Project(
    name="mlops-example",
    shared_secrets=[S3StorageConfig],  # Available to all components
    
    workers=[background],  # Background processes that run continuously

    mlflow_server=MlflowServer(
        domain_names=[
            "example.aligned.codes"  # Auto-configured with HTTPS
        ]
    ),

    is_legendary_app=StreamlitApp(
        main,  # The entrypoint function for your Streamlit app
        secrets=[MlflowConfig],  # Only this app gets access to MLflow credentials
        compute=Compute(
            mb_memory_limit=4 * 1024  # Ensure 4GB RAM for data-heavy workloads
        )
    )
)

This single Project definition tells NoBS everything it needs to know:

• Deploy an MLflow server with a custom domain and automatic TLS.
• Provision an S3 bucket (inferred from S3StorageConfig) and configure access.
• Run a Streamlit dashboard that connects to MLflow, with guaranteed memory.
• Launch a background worker to handle long-running jobs like data preprocessing or model training.
• Securely inject secrets only where needed, no over-provisioning of credentials.

You don’t need to write Dockerfiles, manage IAM roles, or script database creation. NoBS analyzes your code and dependencies, then automatically provisions and connects the required infrastructure.

Automtaic Resource Detection

• If you include a MlflowServer, NoBS automatically provisions a PostgreSQL database and persistent artifact storage (e.g., S3).
• If you use RedisQueue in a Worker, it provisions a managed Redis instance.
• If your app uses S3StorageConfig, it creates a secure S3 bucket with proper IAM policies and injects credentials only into components that declare the secret.
• If you define a Worker that connects to a database via DatabaseConnection, NoBS detects that and provisions a PostgreSQL or MySQL instance, depending on the driver used.

This means you don’t have to manually define infrastructure blocks like you would in Terraform. Instead, NoBS traces secret and configuration usage through your app components and infers exactly what external resources are needed, and how they should be connected.

The result? You get the full power of infrastructure-as-code without the boilerplate. Resources are created, encrypted, network-isolated, and securely linked to your services, automatically.