Skip to main content

CloudBridge provides a consistent layer of abstraction over different Infrastructure-as-a-Service cloud providers, reducing or eliminating the need to write conditional code for each cloud.

Documentation

Detailed documentation can be found at http://cloudbridge.cloudve.org.

Build Status Tests

Integration Tests Code Coverage latest version available on PyPI Documentation Status Download stats

Provider/Environment

Python 3.13

Amazon Web Services

aws-py313

Google Cloud Platform

gcp-py313

Microsoft Azure

azure-py313

OpenStack

os-py313

Mock Provider

mock-py313

Installation

Install the latest release from PyPi:

pip install cloudbridge[full]

For other installation options, see the installation page in the documentation.

Usage example

To get started with CloudBridge, export your cloud access credentials (e.g., AWS_ACCESS_KEY and AWS_SECRET_KEY for your AWS credentials) and start exploring the API:

from cloudbridge.factory import CloudProviderFactory, ProviderList

provider = CloudProviderFactory().create_provider(ProviderList.AWS, {})
print(provider.security.key_pairs.list())

The exact same command (as well as any other CloudBridge method) will run with any of the supported providers: ProviderList.[AWS | AZURE | GCP | OPENSTACK]!

Citation

N. Goonasekera, A. Lonie, J. Taylor, and E. Afgan, “CloudBridge: a Simple Cross-Cloud Python Library,” presented at the Proceedings of the XSEDE16 Conference on Diversity, Big Data, and Science at Scale, Miami, USA, 2016. DOI: http://dx.doi.org/10.1145/2949550.2949648

Quick Reference

The following object graph shows how to access various provider services, and the resource that they return.

CloudBridge Quick Reference

Design Goals

  1. Create a cloud abstraction layer which minimises or eliminates the need for cloud specific special casing (i.e., Not require clients to write if EC2 do x else if OPENSTACK do y.)

  2. Have a suite of conformance tests which are comprehensive enough that goal 1 can be achieved. This would also mean that clients need not manually test against each provider to make sure their application is compatible.

  3. Opt for a minimum set of features that a cloud provider will support, instead of a lowest common denominator approach. This means that reasonably mature clouds like Amazon and OpenStack are used as the benchmark against which functionality & features are determined. Therefore, there is a definite expectation that the cloud infrastructure will support a compute service with support for images and snapshots and various machine sizes. The cloud infrastructure will very likely support block storage, although this is currently optional. It may optionally support object storage.

  4. Make the CloudBridge layer as thin as possible without compromising goal 1. By wrapping the cloud provider’s native SDK and doing the minimal work necessary to adapt the interface, we can achieve greater development speed and reliability since the native provider SDK is most likely to have both properties.

Contributing

Community contributions for any part of the project are welcome. If you have a completely new idea or would like to bounce your idea before moving forward with the implementation, feel free to create an issue to start a discussion.

Contributions should come in the form of a pull request. We strive for 100% test coverage so code will only be accepted if it comes with appropriate tests and it does not break existing functionality. Further, the code needs to be well documented and all methods have docstrings. We are largely adhering to the PEP8 style guide with 80 character lines, 4-space indentation (spaces instead of tabs), explicit, one-per-line imports among others. Please keep the style consistent with the rest of the project.

Conceptually, the library is laid out such that there is a factory used to create a reference to a cloud provider. Each provider offers a set of services and resources. Services typically perform actions while resources offer information (and can act on itself, when appropriate). The structure of each object is defined via an abstract interface (see cloudbridge/providers/interfaces) and any object should implement the defined interface. If adding a completely new provider, take a look at the provider development page in the documentation.

Release files for cloudbridge 4.4.2

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for cloudbridge 4.4.2
File Size Uploaded
cloudbridge-4.4.2.tar.gz 231.3 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for cloudbridge 4.4.2
File Interpreter ABI Platform
cloudbridge-4.4.2-py3-none-any.whl Python 3 none any Details

Total release size: 438.3 kB

Release files / cloudbridge-4.4.2.tar.gz

Download URL cloudbridge-4.4.2.tar.gz
Size 231.3 kB
Tags Source
SHA-256 checksum
How to use checksums
890efed9414016c89e7a078b4fac90900cfd8e5aa02a9969490d66f8731b077a
BLAKE2b-256 checksum
How to use checksums
da3ab9a42f3f7909966219ccd3a2b12dd2f4f0f9f1d2e38aa43984f7dcf88578
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.13

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 18, 2026.

Transparency log

Release files / cloudbridge-4.4.2-py3-none-any.whl

Download URL cloudbridge-4.4.2-py3-none-any.whl
Size 206.9 kB
Tags Python 3
SHA-256 checksum
How to use checksums
525f5ded63b5d4583efed4ea62aa456f66d6a207e91b7d02136f802ab0219c59
BLAKE2b-256 checksum
How to use checksums
feaf4077be1ea52d69fb275c81e8aafed63534f17fcd748cb03e8d759add7c22
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.13

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 18, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

4.4.2 This release

2 release files

4.4.1

2 release files

4.4.0

2 release files

4.3.1

2 release files

4.3.0

2 release files

4.2.1

2 release files

4.2.0

2 release files

4.1.0

2 release files

4.0.0

2 release files

3.2.0

2 release files

3.1.0

2 release files

3.0.0

2 release files

2.2.0

2 release files

2.1.0

2 release files

2.0.0

2 release files

1.0.2

2 release files

1.0.1

2 release files

1.0.0

2 release files

0.3.3

1 release file

0.3.2

2 release files

0.3.1

2 release files

0.3.0

2 release files

0.2.0

1 release file

0.1.1

1 release file

0.1.0

1 release file

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page