Providers
The compute providers Portal runs jobs on, how you connect each one, and what a connection does and does not give you.
Warnings and limits
- A connection is checked with the provider when you save it (60 s at most). It does not mean you have quota or capacity: see Quotas and capacity.
- A workspace holds at most 24 connections, and at most 8 for one cloud.
- Notice before a machine is taken away differs by provider: AWS spot 2 minutes, Google Cloud spot 120 s (25 s when Google refuses the longer notice), Azure spot VMs 20 s, Modal GPU sandboxes 5 s, Azure Container Apps, Lambda and on-demand machines none (a Container Apps stop ends the replica at once, and progress since the job's last checkpoint is lost). The plan warns when a spot offer's notice cannot save the job's state.
portal disconnectdeletes Portal's stored credentials only. It does not delete what--from-climade in your cloud account, and it is refused while a machine runs on the connection or a job is pinned to it.- An Azure connection runs Azure VMs (the route
azure) and Azure Container Apps (the routeaca). A Container Apps job pulls Portal's node image from a Basic container registry that Portal makes in your subscription at your first Container Apps job (resource groupsoma, a name startingportal); Azure bills the registry until you delete it, and Portal makes it again when it is needed. See Azure. - Modal's L4 pool is often short of capacity: a Modal job pinned to one GPU type ends
no_capacityafter 5 minutes without it, with Modal's other GPU types to choose; T4, A10 and A10G start at once as a rule. See Modal.
What you can connect
| Provider | What Portal starts | How you connect | Spot | Notice |
|---|---|---|---|---|
| AWS | EC2 instances | a role Portal assumes (recommended), or an access key | yes | 2 minutes |
| Google Cloud | Compute Engine VMs | a service account key, or keyless federation where offered | yes | 120 s (25 s fallback) |
| Azure | Azure VMs, and Azure Container Apps | a federated credential (recommended), or a client secret | VMs: yes | VMs: 20 s; Container Apps: none (a stop ends the replica at once) |
| Modal | Modal sandboxes | a Modal token | GPU sandboxes can be preempted | 5 s |
| Lambda | Lambda Cloud instances | an API key | no | none |
| Your own machines | runs on a computer you enroll | an enrollment code and a pairing code | no | none |
Connect from the CLI
Find the cloud CLIs that are signed in on this machine. This only reads:
portal connect --detectConnect one with its CLI's login, in your own account:
portal connect aws --from-cli
portal connect gcp --from-cli --project my-project
portal connect azure --from-cli
portal connect lambda --from-cli--from-cli prints every step it will take in your account and asks before it makes anything. --yes skips the question (the steps are still printed), and --plan PLAN_ID goes ahead only with a plan an earlier --json run printed.
To connect from a file of KEY=value lines (for example MODAL_TOKEN_ID and MODAL_TOKEN_SECRET, LAMBDA_API_KEY, or a Google Cloud service account JSON file with gcp):
portal connect modal --file modal.envportal connect with no provider lists your connections, and in your own terminal opens the console's Connect page.
Connect from the console
The console's Connect page at portal.clusy.io/app lists the providers, the methods each takes and the fields each method needs. Adding or changing a connection needs a Clusy sign-in from the last 5 minutes.
Named connections
A workspace can hold more than one connection to a cloud, for example two AWS accounts. Each extra one has a label: aws.research, gcp.lab. A label is 1 to 24 lowercase letters, digits or hyphens, and does not start with a hyphen. Use the full name wherever a command takes a connection, and in --on specs.
Spending caps
Each connection can carry a spending cap in US dollars:
portal connect aws --from-cli --cap 200Portal refuses a machine whose worst-case cost would take the connection's committed spend over its cap. See Spend caps and budgets.
Remove a connection
portal disconnect aws.researchPortal deletes the credentials it stored. Roles, service accounts, apps or keys that --from-cli made in your account stay there; remove them in your provider's console if you no longer want them.