```
### Step 4. Optional. Verify the status of your deployment
1. Check the status of your deployment:
**Operator:**
To check the status of the Materialize operator, which runs in the `materialize` namespace:
```bash
kubectl -n materialize get all
```
**Materialize instance:**
To check the status of the Materialize instance, which runs in the `materialize-environment` namespace:
```bash
kubectl -n materialize-environment get all
```
If you run into an error during deployment, refer to the
Troubleshooting.
### Step 5: Connect to Materialize
You can connect to Materialize via the Materialize Console or
PostgreSQL-compatible tools/drivers using the following ports:
| Port | Description |
| --- | --- |
| 6875 | For SQL connections to the database |
| 6876 | For HTTP(S) connections to the database |
| 8080 | For HTTP(S) connections to Materialize Console |
#### Connect using the Materialize Console
> **Note:** - **If using a public NLB:** Both SQL and Console are available via the
> public NLB. You can connect directly using the NLB's DNS name from anywhere
> on the internet (subject to your `ingress_cidr_blocks` configuration).
> - **If using a private (internal) NLB:** You can connect from inside the same VPC or from networks that are privately connected to it. Alternatively, use Kubernetes port-forwarding for both SQL and Console.
Using the `console_load_balancer_ip` and `external_login_password_mz_system`
from the Terraform output, you can connect to Materialize via the Materialize
Console.
1. To connect to the Materialize Console, open a browser to
`https://:8080`, substituting your
``.
From the terminal, you can type:
```sh
open "https://$(terraform output -raw console_load_balancer_ip):8080/materialize"
```
> **Tip:** The example uses a self-signed ClusterIssuer. As such, you may encounter a
> warning with regards to the certificate. In production, run with
> certificates from an official Certificate Authority (CA) rather than
> self-signed certificates.
1. Log in as `mz_system`, using `external_login_password_mz_system` as the
password.
1. Create new users and log out.
In general, other than the initial login to create new users for new
deployments, avoid using `mz_system` since `mz_system` also used by the
Materialize Operator for upgrades and maintenance tasks.
For more information on authentication and authorization for Self-Managed
Materialize, see:
- [Authentication](/security/self-managed/authentication/)
- [Access Control](/security/self-managed/access-control/)
1. Login as one of the created user.
#### Connect using `psql`
> **Note:** - **If using a public NLB:** Both SQL and Console are available via the
> public NLB. You can connect directly using the NLB's DNS name from anywhere
> on the internet (subject to your `ingress_cidr_blocks` configuration).
> - **If using a private (internal) NLB:** You can connect from inside the same VPC or from networks that are privately connected to it. Alternatively, use Kubernetes port-forwarding for both SQL and Console.
Using the `balancerd_load_balancer_ip` and `external_login_password_mz_system`
from the Terraform output, you can connect to Materialize via
PostgreSQL-compatible clients/drivers, such as `psql`:
1. To connect using `psql`, in the connection string, specify:
- `mz_system` as the user
- `balancerd_load_balancer_ip` as the host
- `6875` as the port:
```bash
psql "postgres://mz_system@$(terraform output -raw balancerd_load_balancer_ip):6875/materialize"
```
When prompted for the password, enter the
`external_login_password_mz_system` value.
1. Create new users and log out.
In general, other than the initial login to create new users for new
deployments, avoid using `mz_system` since `mz_system` also used by the
Materialize Operator for upgrades and maintenance tasks.
For more information on authentication and authorization for Self-Managed
Materialize, see:
- [Authentication](/security/self-managed/authentication/)
- [Access Control](/security/self-managed/access-control/)
1. Login as one of the created user.
## Customizing Your Deployment
> **Tip:** To reduce cost in your demo environment, you can tweak machine types and database tiers in `main.tf`.
You can customize each module independently.
- For details on the Terraform modules, see both the [top
level](https://github.com/MaterializeInc/materialize-terraform-self-managed/tree/main)
and [GCP
specific](https://github.com/MaterializeInc/materialize-terraform-self-managed/tree/main/gcp)
modules.
- For details on recommended instance sizing and configuration, see the [GCP
deployment
guide](/self-managed-deployments/deployment-guidelines/gcp-deployment-guidelines/).
> **Note:** **GCP Storage Authentication Limitation:** Materialize currently only supports HMAC key authentication for GCS access (S3-compatible API). While the modules configure both HMAC keys and Workload Identity, Materialize uses HMAC keys for actual storage access.
See also:
- [Configuring System
Parameters](/self-managed-deployments/configuration-system-parameters/)
- [Materialize Operator
Configuration](/self-managed-deployments/operator-configuration/)
- [Materialize CRD Field
Descriptions](/self-managed-deployments/materialize-crd-field-descriptions/)
## Cleanup
To delete the whole sample infrastructure and deployment (including the
Materialize operator and Materialize instances and data), run from the Terraform
directory:
```bash
terraform destroy
```
When prompted to proceed, type `yes` to confirm the deletion.
## See Also
- [Troubleshooting](/self-managed-deployments/troubleshooting/)
- [Security](/security/self-managed/)