---
sidebar_label: Overview
doc_id: f7d1c1f4-498f-4a30-a62f-550f47f95e04
description: >-
  Connect nullplatform with GitHub, Azure, AWS and other 3rd-party services
  through simplified provider configurations.
keywords:
  - providers
  - integrations
  - third-party services
  - cloud platforms
  - configuration
---

# Overview

## Learn about providers

### What are providers? why should I care?

Providers allow you to connect nullplatform with GitHub, Azure, AKS, and more 3rd-party services (or providers). It
works by asking you a series of information about the provider being connected and taking care of configuring every
aspect of the platform, so you can integrate and leverage those services.

Providers greatly simplify the way you configure nullplatform to use 3rd-party services because it:

- clearly states what information is needed to configure a provider,
- acts as a single entry-point for configurations that actually span across many nullplatform's subsystems

Note that providers are used to set up and configure nullplatform, it's important to note that we don't manage your
subscription
to your provider nor infrastructure or resources other than the ones needed to integrate them to nullplatform. For
example, we can create a GitHub repository as part of application creation, but we do not manage your GitHub plans or
Co-pilot subscription.

### Integrations

The collection of 3rd-party services we support as providers are called "Integrations". We provide JSON specifications
for services such as:

- **Cloud platforms**: AWS, Google Cloud Platform, Microsoft Azure
- **Version control systems**: GitHub, GitLab, Azure DevOps, Bitbucket
- **Container orchestration**: AKS, EKS, GKE
- **Logging and metrics**: Datadog, Dynatrace, Prometheus, AWS CloudWatch

Click on this link to check the complete list of [supported integrations](/docs/providers/supported-integrations/index.md).

### Inheritance and overrides

Providers can be configured for the whole organization, for some account, namespaces, applications, or even scopes.

This means that when you configure a provider at a certain level, any node at or below that level will have the same
provider configuration. This is, if you configure GitHub or a Kubernetes cluster at the organization level, all
applications will be using that provider or configuration.

#### But what happens when I want to change the behavior for certain accounts, namespaces, etc.?

This is where **inheritance** takes a role. In this case you would create a new configuration, but at a lower level,
overriding some configuration that you have set on the parent levels. For example, if we have configured the cluster "
Cluster A" at the organization level, then you could configure "Cluster B" for a specific namespace or application by
creating the provider configuration and specifying the level where that configuration take place.

Inheritance works the same way for providers as it work for NRN, so you can [read about NRN](/docs/NRN.md) to learn more
on the topic,

### Configurations that depend on another one

Configurations may require another configuration to be already set for the provider to function correctly. For example,
to configure **Elastic K8S Service (EKS)** you're required to previously configure **AWS**.

While we will tell you whenever you're in this situation, you can always check the comprehensive list of configuration
dependencies in the [provider integrations section](/docs/providers/supported-integrations/index.md).

### Secrets and credentials

Whenever a secret or sensitive parameter is saved as part of a configuration, only users using authorized API keys can
access and retrieve secrets, which will come in handy when you provision your configurations with OpenTofu/Terraform.

## Configure a provider

### OpenTofu/Terraform (recommended)

Nullplatform offers a custom OpenTofu/Terraform provider, allowing you to manage your nullplatform resources, including
provider configurations and much more.

**1. Add the provider to your Terraform configuration:**

```hcl
terraform {
  required_providers {
    nullplatform = {
      source = "nullplatform/nullplatform"
    }
  }
}

provider "nullplatform" {
  api_key = "your-api-key"
}
```

**2. Create your first provider configuration:**

```hcl
resource "nullplatform_provider_config" "azure-configuration" {
  account = "example-account"
  type    = "azure-configuration"
  
  dimensions = {}
  
  attributes = jsonencode({
    "networking": {
      "domain_name": "example.com",
      "public_dns_zone_name": "public.example.com",
      "public_dns_zone_resource_group_name": "my-public-dns-resource-group",
    },
    "authentication": {
      "client_id": "12345678-1234-1234-1234-123456789012",
      "tenant_id": "87654321-4321-4321-4321-210987654321",
      "client_secret": "ThisIsAMockSecretDoNotUseInProduction!",
      "subscription_id": "11111111-2222-3333-4444-555555555555"
    }
  })
}
```

### API

The typical usage of the provider configuration feature is through our API. All endpoints can be found in the API
section of our documentation.

## Tutorials

If you are interested in setting up your provider configs using OpenTofu/Terraform, please refer to any of our
tutorials:

- [Setting up a new account](/docs/providers/tutorials/setting-up-new-account/index.mdx)
- [Setting up GCP and GKE](/docs/providers/tutorials/setting-up-gcp-and-gke.mdx)
- [Importing existing configurations into OpenTofu/Terraform](/docs/providers/tutorials/importing-existing-configurations-into-terraform.mdx)
- [Configuring GitHub organization](/docs/providers/tutorials/configuring-github)

## Reference

- [Terraform Registry documentation](https://registry.terraform.io/providers/nullplatform/nullplatform/latest/docs)
- [Nullplatform's Terraform provider GitHub repository](https://github.com/nullplatform/terraform-provider-nullplatform)