Organizations on Paralon: One GPU Budget, Shared API Keys and a Role for Everyone on the Team

Until this week a Paralon account was a person. That works for one developer with one API key. It stops working the moment a second person joins: the company's card sits on someone's personal account, the API key that production uses was made by whoever happened to be logged in, and when that person leaves nobody is sure what they still have access to.

Organizations fix that. An organization is a workspace a team shares, with one credit balance, its own API keys, rentals, render jobs, nodes and earnings, its company details, and a role for every member that decides what they can see and do. It is live for every account: open the account menu and choose Create organization. The documentation has every rule; this article is about how it fits together and why we built it this way.

What an organization is

Your personal account does not change and does not move. An organization starts empty: you add credits to it, create its API keys and add its nodes from inside it. Nothing ever moves between your personal account and an organization, which keeps both ledgers simple to read.

How you work in one

The account menu lists Personal and every organization you belong to, with your role in each. What you pick is where you work: the balance, the keys, the rentals and the invoices on every page are that workspace's, and a line at the top of the page says which one you are in and as what. Top up while working in the organization and the credits are the organization's; start a rental and it is billed to the organization.

API keys follow a stricter rule, because they run in scripts and servers where nobody is looking at the site: a key always bills the workspace it was created in. A key made in the organization spends the organization's credits forever, whatever its creator does on the site afterwards. That is what you want from the key in your production config, and it is the reason a key records who made it.

Five roles, one rule for money

Every action on Paralon has a permission, and every role is a list of them. The five roles are the ones most teams already know from other tools:

The full matrix, permission by permission, is in the Organizations guide.

One rule sits above the table: money that leaves the organization needs an Owner or a Billing member, never an Admin alone. Requesting a payout and changing where payouts are sent are not part of the Admin role. A compromised or careless Admin account can do a lot of damage to a team's resources; it cannot send the team's earnings somewhere else. When the payout destination does change, every Owner and Billing member gets an email, and nothing is paid to the new destination for 48 hours, which is long enough to notice and undo a change nobody expected. Taking over an account and changing where money goes is the most common pattern in account fraud, which is why this one action gets a waiting period of its own.

The rest of the rules are the ones a team needs to stay governable: an organization always has at least one Owner, nobody can change their own role, an Admin cannot touch an Owner or make one, and ownership is handed over only when the new Owner accepts it.

Inviting people

Owners and Admins invite by email address and choose the role in the same step. The invitation comes from Paralon with a link that works for seven days, and only when the person is signed in with the address it was sent to; a forwarded link is useless to anyone else. They can accept with an account they already have or create one on the spot. Pending invitations can be sent again or revoked.

An organization has ten seats, counting members and pending invitations, and can send as many invitations a day as it has seats. Teams that need more write to us.

Removing a member, or a member leaving, revokes the API keys they made in the organization at once. Their running rentals keep running: stopping paid work that a teammate started is the team's decision, made with a button, not a side effect of someone's account being closed.

If you provide GPUs

Organizations are not only for teams that rent. A business that earns with its GPUs on Paralon, a studio whose workstations work at night, a gaming cafe after hours, a data center selling spare capacity, gets the same structure on the earning side:

• The nodes are the company's, not one person's. Add them from inside the organization and they belong to it. Nothing depends on the account of whoever happened to install the agent, and when that person leaves, the machines and what they earn stay with the team.
• Owners and Admins run the machines. They add, change and delete nodes, set their prices, pause and resume spot nodes, and get the alerts when a node goes unhealthy or comes back online. Developers and Billing members do not touch nodes.
• Earnings land in one place. What all the team's nodes earn adds up in the organization. Owners, Admins, Billing members and Viewers see it; Developers do not.
• Payouts follow the rule for money. Only an Owner or a Billing member can request a payout or change where it goes, in USDC or, for a company, by bank transfer in the company's name. A change of destination is announced to every Owner and Billing member and held for 48 hours before anything is paid there.
• Every change is on the record. Nodes added and changed, payouts requested and destinations changed are in the activity log, with who did it.

Company details, invoices and bank payouts

A team usually is a company, and companies need paperwork in their own name. In an organization, Settings → Company details are the organization's:

• Card top-ups are invoiced with the company details entered at checkout (name, address, VAT number), and the card receipt goes to the member who paid, not to a shared inbox.
• Bank payouts of the organization's earnings, for teams that run nodes, need the company's legal details and bank account, with a proof of that account. We check them once. Payouts are then invoiced in the company's name automatically (how payouts work).

Owners and Billing members fill these in. Admins and Viewers see the company's details but not the bank account: we remove it on the server for anyone whose role cannot move money, so it is not merely hidden in the page.

Listing data-center capacity

Data centers and companies with their own GPU servers can rent them out, reserved for one buyer, through the capacity directory. Listing is done by an organization, in two short steps, each when it is needed:

1. List the company. In Settings, under Capacity directory: name, country, logo, website and a description. We take a quick look, with no documents, and the company gets a public page with its listings.
2. Add listings. Under Reserved capacity: the GPU, how many per server, how many servers, where they are, the price per GPU-hour, the minimum term and any down payment. Each listing is reviewed before it goes live.

Being paid by bank is separate and comes later, when a deal is real: that is when the company adds its legal details and bank account. Nobody has to hand over a bank account just to try the directory. The listing guide has every field, and reserved capacity without a down payment explains how a deal runs once a buyer asks.

The activity log

Every organization has a log of who did what: invitations, role changes and removals; API keys created, changed and revoked; rentals started and stopped, with the GPU and the price; nodes added and changed; top-ups started, payouts requested and payout destinations changed. Owners, Admins and Billing members can filter it by person or by area and export it as CSV for an audit or the accountant.

The log is append-only in the database: updates and deletes are refused by a trigger, for everyone, including our own staff and our own code. It is kept for the life of the organization. A log that someone could clean up afterwards would not be worth keeping.

How it is built

A few decisions that matter if you are trusting a team's money to this:

• One permission registry decides. Every permission and every role's grants live in one place in our API, and every route of the site that acts for an account declares the permission it needs. The site will not build if a route declares none, so a new page cannot quietly ship without a check. The public matrix in the guide is tested against the registry on every regression run.
• Every account already has a workspace. Before organizations existed, we gave every account a personal workspace and tagged every balance, ledger row, key, rental and node with the workspace that owns it. The migration ran table by table in short transactions; rehearsed on a full copy of production under billing-like traffic, the slowest statement during it took 45 milliseconds.
• Checks fail closed. If the permission check cannot get an answer, the action is refused with an error, never allowed.
• Nothing is ever free by accident. The free trial stays per person: an organization never gets a free API key, so a new team is not a new trial.

Start one

Open the account menu, choose Create organization, give it a name and invite your team. The Organizations guide covers every role, rule and email in detail. If your team needs something the roles above do not cover, write to us at [email protected]: the registry was built to take custom roles when someone needs them.