Skip to main content
Pulumi logo

Python for DevOps

11 min read

Python is the most common general-purpose language for DevOps work: writing automation scripts, defining infrastructure as code, building CI/CD glue, instrumenting observability, and running the data and machine-learning pipelines that increasingly sit alongside traditional services. Its readable syntax, deep standard library, and large ecosystem of vendor SDKs make it the path of least resistance whenever a DevOps team needs to wire two systems together or replace a manual task with a script.

Python’s role in DevOps grew naturally from its role in sysadmin scripting and scientific computing. The same language that powers boto3, kubernetes client libraries, Ansible modules, and Jupyter notebooks now also powers full infrastructure as code programs, MLOps pipelines, and FinOps tooling. For a team that’s already using Python for application code or data work, choosing it for DevOps reduces the number of languages the organization has to maintain.

In this article, we’ll cover the key questions about Python for DevOps:

  • Why is Python so popular for DevOps?
  • Where do DevOps engineers actually use Python?
  • How is Python used for infrastructure as code?
  • How is Python used for MLOps?
  • What does the Python DevOps toolchain look like?
  • What are best practices for Python in DevOps?
  • How does Pulumi support Python?
  • Frequently asked questions about Python for DevOps

A handful of properties keep Python at the top of DevOps language surveys year after year:

  • Readability. Python’s syntax is forgiving and close to pseudocode, so on-call engineers can read and edit each other’s scripts without weeks of ramp-up. That matters more for ops tooling than for application code, because the same script may be touched by SREs, security engineers, data engineers, and product engineers.
  • A library for everything. PyPI has wrappers for almost every major cloud API, messaging system, monitoring vendor, and IaC and configuration tool. Most DevOps tasks reduce to glue code on top of existing libraries.
  • The data and ML overlap. Pandas, NumPy, scikit-learn, PyTorch, and TensorFlow live in the same language. As MLOps pipelines mature, the DevOps team that already knows Python can ship them without picking up a second language.
  • First-class IaC support. Modern IaC tools, including Pulumi, support Python natively. The same engineers who wrote the deploy scripts can write the platform itself.
  • Cloud and Kubernetes SDKs. Every major provider ships an official Python SDK: boto3 (AWS), google-cloud-* (Google Cloud), azure-sdk-for-python (Azure), the Kubernetes Python client. The first thing a DevOps engineer reaches for is usually one of these.

Where do DevOps engineers actually use Python?

DevOps work has gotten broad enough that a single chart of “what Python is for” tends to leave things out. A reasonable taxonomy:

AreaWhat Python does
Infrastructure as codeDefine cloud resources as a Python program with Pulumi; describe Ansible modules and roles; write CDK programs that synthesize CloudFormation
Configuration managementAnsible playbooks (YAML) plus custom modules in Python; SaltStack
CI/CD glueBuild steps, deployment scripts, release-engineering tooling that runs in GitHub Actions, GitLab CI, Jenkins, Buildkite
Cloud automationOne-off and scheduled scripts using boto3/google-cloud/azure-sdk for housekeeping, audits, and remediation
Observability and alertingCustom collectors, Datadog/New Relic/Prometheus exporters, OpenTelemetry instrumentation, log shippers
ChatOps and runbooksSlack/Teams bots, on-call automation, incident response scripts
Security and complianceIAM analyzers, secret scanners, custom Open Policy Agent / Pulumi policy packs, vulnerability scanning glue
MLOpsTraining pipelines, model serving, feature stores, experiment tracking (MLflow, Weights & Biases)
FinOpsCost-tagging audits, budget reports, anomaly detection on cloud spend

What’s common across the list: Python is rarely the only language, but it’s almost always one of the languages.

How is Python used for infrastructure as code?

Python is one of the primary languages for IaC tools that support real programming languages (alongside TypeScript, Go, .NET, and Java). With Pulumi, a Python IaC program describes the desired state of cloud infrastructure as ordinary Python classes and functions:

  • Generated, typed SDKs. Pulumi’s Python providers ship type hints for every cloud resource (AWS, Azure, Google Cloud, Kubernetes, Cloudflare, Datadog, Snowflake, and more). IDEs like PyCharm and VS Code surface the available properties as you type.
  • Real abstractions. A reusable VPC pattern becomes a Python class (MyVpc(...)), not a folder of templates. Components can ship as PyPI packages.
  • Standard testing tools. pytest, unittest, mocks via unittest.mock, and Pulumi’s own Python mocks for cloud responses. IaC tests run alongside application tests in the same CI job.
  • Standard packaging. pip, poetry, uv, or Pipenv manage dependencies. Lock files (requirements.txt, poetry.lock, uv.lock) make deploys reproducible.

Compared to writing infrastructure in HCL or YAML, Python gives you loops, conditionals, classes, type hints, and the ability to share modules through PyPI. Compared to writing infrastructure in TypeScript, the team trades off some compile-time type rigor for the language they’re already using. Both options are first-class in Pulumi; the right one depends on what your team writes most of its other code in.

For a deeper look at IaC concepts, see What is Infrastructure as Code? and Infrastructure as Code for DevOps.

How is Python used for MLOps?

MLOps is the application of DevOps practices to machine-learning systems: version control for models and training data, CI/CD for retraining pipelines, observability of model behavior in production, and rollback when a model regresses. Python is the dominant language across MLOps:

  • Training pipelines. Frameworks like PyTorch, TensorFlow, JAX, and Hugging Face Transformers are Python-first.
  • Pipeline orchestration. Tools like Airflow, Prefect, Dagster, Kubeflow, Metaflow, and ZenML use Python as the orchestration language.
  • Experiment tracking. MLflow, Weights & Biases, and Neptune all expose Python-first APIs.
  • Serving. FastAPI, BentoML, Seldon Core, KServe, and Triton’s Python client all sit in the Python ecosystem.
  • Feature stores. Feast, Tecton, and Hopsworks ship Python SDKs.

The practical consequence is that a DevOps team that already knows Python can sit alongside the data and ML teams without translating between languages. The same pulumi up that provisions a model serving stack, the same pytest that tests the IaC, and the same boto3 script that audits cost can all live in one Python codebase. See data science in the cloud for a deeper take on the overlap.

What does the Python DevOps toolchain look like?

A typical Python toolchain for DevOps work:

CategoryRepresentative tools
Package managementpip, uv, Poetry, Pipenv
Virtual environmentsvenv, virtualenv, conda
Type checkingmypy, Pyright, pyre
Linting and formattingRuff, Flake8, Pylint, Black
Testingpytest, unittest, hypothesis, tox
CI/CDGitHub Actions, GitLab CI, CircleCI, Jenkins, Buildkite
Infrastructure as codePulumi, Ansible
Cloud SDKsboto3, google-cloud-* (GCP), azure-sdk-for-python, kubernetes
Orchestration / pipelinesAirflow, Prefect, Dagster, Argo Workflows
ML / MLOpsPyTorch, TensorFlow, scikit-learn, MLflow, Kubeflow, BentoML
ObservabilityOpenTelemetry Python SDK, Datadog APM, New Relic, Sentry
SecretsPulumi ESC Python SDK, HashiCorp Vault client, AWS Secrets Manager

The toolchain isn’t static. Astral’s uv and ruff have displaced a lot of older tools in the last two years; both are dramatic speedups over their predecessors and are now common defaults in new Python projects.

What are best practices for Python in DevOps?

A few patterns that hold up across team sizes:

  • Use a fast resolver. uv or Poetry, with a checked-in lock file. requirements.txt alone doesn’t pin transitive dependencies, which causes “works on my machine” failures.
  • Enable type hints and run a checker. mypy or Pyright on every PR. Even partial typing pays off because cloud SDKs have complex shapes.
  • Use Ruff for linting and formatting. Combines what Flake8 + Black + isort + pyupgrade used to do, runs orders of magnitude faster, and ships with sensible defaults.
  • Pin Python versions. Use pyproject.toml to declare a supported Python range, and use .python-version (or tool.uv.python) to pin a specific local version. Production drift between Python versions is a real source of bugs.
  • Don’t hide secrets in .env files. Use Pulumi ESC, Vault, or your cloud’s secrets manager and pull them at runtime. Commit .env.example if you have to, never .env.
  • Test the scripts. Even short DevOps scripts deserve a pytest run. A test that simulates the boto3 call with a mock catches the API regressions cloud SDKs introduce.
  • Containerize CI jobs that depend on system packages. A Dockerfile beats trying to make a CI image match a developer laptop.
  • Prefer libraries over invoking subprocesses. boto3 over shelling out to aws; the kubernetes client over kubectl. The library calls are easier to test and easier to handle errors from.

How does Pulumi support Python?

Python is a first-class language for Pulumi, supported on par with TypeScript, Go, .NET, and Java.

  • Typed SDKs for every cloud. AWS, Azure, Google Cloud, Kubernetes, Cloudflare, Snowflake, Datadog, and hundreds of other providers. Generated from each provider’s API, including full type hints and docstrings.
  • pulumi new python. Creates a project with a Pulumi.yaml, a virtualenv setup, and a starter program in seconds. See the Python language guide and the get-started flow.
  • Component model. Reusable Pulumi components can be distributed as PyPI packages with full type hints, among other formats.
  • Crosswalk for AWS. Higher-level abstractions for common AWS patterns wrapped in idiomatic Python.
  • Unit testing with mocks. Pulumi’s Python test mocks replace cloud calls with canned responses so pytest runs in milliseconds.
  • Automation API. The automation API lets you call Pulumi from inside another Python application. Build self-service portals, CLIs, or CI jobs that drive pulumi up programmatically.
  • Pulumi policies in Python. Write policy as code in the same language as your infrastructure.
  • Pulumi ESC for secrets. Pulumi ESC pulls secrets at runtime into Python programs, CI jobs, and applications.

Get started with Pulumi and Python to provision cloud infrastructure with the language your team is already using.

Frequently asked questions about Python for DevOps

Is Python a good language for DevOps?

Yes, for most teams. Its readability, library ecosystem, and overlap with data/ML work make it the default scripting language for ops tasks. Pure performance-sensitive systems work tends to use Go or Rust, but for the broad middle of DevOps automation, Python is the most common choice.

Should I use Python or Bash for DevOps scripts?

Bash is fine for very short scripts that wrap a few commands. Anything that has to parse JSON, talk to a cloud API, retry on failure, or be tested should be in Python. The transition point comes earlier than most people expect, around the time a Bash script grows past a screen.

Is Python better than YAML for IaC?

For teams that already write Python, almost always yes. YAML has no real abstractions, no real testing, and no type system. Python has all three. The trade-off is a slightly higher floor for an engineer with no Python background, but most cloud teams have someone who knows Python.

Should I use Python or TypeScript for Pulumi?

Pick the language your team writes most of its other code in. Both are first-class in Pulumi. Python tends to win when there’s overlap with data/ML work; TypeScript tends to win when there’s overlap with full-stack web work. The cloud coverage and feature set are equivalent.

How do you test Python IaC?

Use pytest and Pulumi’s Python test mocks for unit tests, run a static scanner like Checkov against the rendered output, run Pulumi policies in CI, and use the automation API to spin up ephemeral stacks for integration tests.

What’s MLOps and how does it relate to DevOps?

MLOps applies DevOps practices (version control, CI/CD, observability, rollback) to machine-learning models and the pipelines that produce them. The two disciplines overlap in tooling but diverge in subject matter: DevOps ships application services; MLOps ships models, datasets, and the training and serving infrastructure around them. Python is dominant in both.

What Python tools have changed recently?

uv (Astral) has displaced pip and a lot of poetry usage as the fast default package manager. ruff (also Astral) has replaced most of the Flake8 / Black / isort stack as a unified, fast linter and formatter. Both are worth adopting in new projects; both can be added to existing projects incrementally.

How does Python compare to Go for DevOps?

Python is better at glue, scripts, IaC, and ML-adjacent work. Go is better at building self-contained binaries, network services, and cloud-native tools (Kubernetes itself, plus a lot of CNCF tooling, is written in Go). Many DevOps shops use both: Python for scripts and IaC, Go for any custom controllers or operators they ship.

How do I handle secrets in a Python DevOps program?

Don’t put secrets in source. Use Pulumi ESC, HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. Pull secrets at runtime using the vendor’s Python SDK or ESC’s pull-at-runtime pattern. Treat .env files as developer convenience for local work only; never commit them.

Can I migrate from Ansible to Pulumi?

Yes, and many teams do. Ansible’s strength is configuring long-lived servers and one-off remote tasks; Pulumi’s strength is provisioning cloud resources and managing them as a versioned, tested codebase. Common migration path: move provisioning to Pulumi first, leave Ansible in place for VM-level configuration that hasn’t moved to containers, retire Ansible as more workloads become immutable.

Learn more

Pulumi treats Python as a first-class IaC language: typed SDKs for every major cloud, components packaged as PyPI modules, pytest with cloud mocks, and the same CI/CD and code review workflow you already use for application Python. Get started today.

Related reading:

Get started today

Pulumi is open source and free to get started. Deploy your first stack today.

Get started

The infrastructure as code platform for any cloud.