Privacy policy

1. Who we are, and what this covers

Broka is a self-hosted broker operations console. This policy is issued by Ayhan Yavuz - Orchesta Teknoloji (“we”, “us”), a sole proprietorship: the individual and the trade name are one legal person, and that person is the controller. English-facing materials may say Ayhan Yavuz - Orchesta Technology; that is the same company, not a second legal person. The name carries no company-form suffix.

Registered office: Küçükbakkalköy Mahallesi, Dereboyu Caddesi, R5 Blok No: 3A/48, 34636 Ataşehir, İstanbul. MERSİS 1121020762200001. Trade registry 1143542.

The company site is orchesta.io. That page currently brands as Orchesta Labs. Broka’s marketing site is broka.dev. Neither is the licence-server hostname or the registry hostname.

“Broka” in this policy is the product. Ayhan Yavuz - Orchesta Teknoloji publishes it and operates the vendor service behind the customer portal and the licence calls.

This policy covers personal information we handle in four places:

1. The marketing site at broka.dev, including its four forms.
2. The customer portal — the account of a person at a customer organisation, on our infrastructure.
3. Licence activation and refresh — the outbound calls a commercial, online-activated installation makes to our licence service.
4. Buying a Commercial licence — which FastSpring handles as the seller, and the record of the order it sends us (§5).

It does not cover what runs inside your own installation. Broker addresses, topic and queue names, messages, users of the product, audit entries, and anything else you operate Broka against stay on your infrastructure. We have no channel into an installation, and none will be built.

A portal account is not a product account. The people who operate your brokers live in your installation. Nothing links the two, and nothing in this policy implies a shared sign-on.

2. What we do not collect from the product

There is no usage reporting, no phone-home of configuration, and no telemetry of what you run. Internet on the host does not change that. Connectivity is how an online commercial installation reaches the licence service. It is not permission to send anything else. OpenTelemetry, if you turn it on, goes to a collector you name; it is off by default and it does not come to us.

What leaves a customer network, when anything leaves at all:

Installation	What leaves
Community	Nothing. There is no key and no activation.
Commercial, activated offline	Nothing. The online path is not attempted.
Commercial, activated online	One HTTPS call at activation, then about one refresh a day — and one more if you release the installation. The lists in §6 are complete.

We do not receive broker addresses, cluster, topic or queue names, connection or secret material, user identities or counts, hostnames, environment names, audit content, or usage of any kind.

The product writes the outbound request body verbatim into its own audit record before it is sent, so you can prove what left without trusting this page.

3. Marketing site — the four forms

The site has four forms. They share one submission contract and they store the same kind of record: what you typed, the page you came from, the exact consent sentence you were shown, and when you agreed.

A submission is sent from your browser straight to the vendor service and stored there. If the page tells you the form is not connected, nothing was sent and nothing was stored — that is the site built without a service to talk to, and the banner is the truth rather than a placeholder.

Request a demo (/request-a-demo). Required: name, work email, company, role, country, broker platforms you run. Optional: environment or cluster scale, tools you use today, deployment model, primary challenge, a free-text message.

Contact sales (/contact-sales). Required: name, work email, company, country, message. Optional: role, edition you are looking at, subject (licensing, support, deployment, a security review, procurement, a custom integration, or other).

Security and deployment overview (/security-overview). Required: name, work email, organisation, country. Optional: role, current deployment model (including air-gapped).

Commercial waitlist (/waitlist). Required: name, work email, company. There is no optional field. It is a list of organisations to write to when the Commercial edition opens; it is not a purchase, a pre-order or a trial, and nothing on it is charged or reserved.

Every form also stores:

• consentText — the sentence shown above the checkbox, verbatim. A tick with no wording is refused. We keep the words you agreed to, not a boolean.
• consentedAt — your moment, not ours.
• source — the page the submission came from.
• kind — demo, sales, security-overview, or waitlist.
• reference — a public handle we can read back to you. It is not the database key.
• outcome — accepted, invalid, duplicate, rate-limited, or failed.

We do not score a lead, enrich it from the email domain, or send it to a third-party form or CRM. There is no CAPTCHA and no script a reviewer of the page cannot explain.

A rate limit may observe the caller address so one address cannot flood the endpoint. That address is not a field on the lead row.

The consent sentences, today:

• Demo and security overview: “I agree to be contacted about this request, and to the privacy policy covering how these details are stored.”
• Sales: “I agree to be contacted about this enquiry, and to the privacy policy covering how these details are stored.”
• Waitlist: “I agree that Broka may store these details and contact me when the Commercial edition opens, and to the privacy policy covering how they are kept.”

4. Customer portal — the account

A Commercial account is opened by the checkout. When an order completes, the record FastSpring sends us (§5) creates the account and invites the person named on the order by email; someone who already has a free account with that address keeps it, with its history. A member of our staff can also create a person under a customer, and then the invitation token is shown once.

A free-edition account is the other way round. Anybody may register one on the customer portal. That form asks for three things and no others: an email address, a name to be called by, and a password. It creates an account that can open a support topic and nothing more — no licence, no key, and no effect whatsoever on a Community installation, which still calls nothing and needs no account to run.

On either kind of account we hold:

• Email address
• Display name
• Whether the person is the organisation’s owner (one per customer; not a role model)
• A password hash, once the invitation is accepted — never the password
• A hash of the unused invitation token, until it is spent
• When the invitation expires
• Failed-sign-in count and, if locked, when it unlocks
• Last successful sign-in time
• Sessions: created, expires, ended, and why it ended (signed_out, password_changed, disabled). No address, no user-agent, no location. A session list that showed those would be a nicer screen and a worse promise.

Signing out ends that session. Disabling the account ends all of them.

We do not run a second factor for customers.

A person who has forgotten their password can ask for a reset link by email. We store only a hash of that link, never the link itself; it works once, and it stops working one hour after it was sent. Asking for one tells the asker nothing about whether the address is registered — the answer is the same either way, deliberately.

Staff can invite again only while the invitation is unused; an accepted account is not a silent reset.

5. The organisation we attach the account to

The customer record is the organisation, not the person. We hold:

• Organisation name (this name is written into the licence token as cust, so it appears inside your product on the next refresh)
• Country, when it was recorded — a commercial fact, not a claim
• An optional free-text purchase-order or reference note. It is not a billing system: we do not issue invoices, take payments or hold a payment method — FastSpring does, as the paragraph at the end of this section says
• Internal notes for whoever picks up the account. They are not shown on your screens
• Against each subscription: who accepted the licence agreement, on what date, and which version. That is a person's name and, where the order carries one, their role — transcribed from your own order rather than collected from them. We keep it because a company's agreement to the terms it bought under is the thing a dispute turns on, and "somebody there pulled an image" is not a record. It is held for as long as the subscription and its successors are, and it is not used for anything else

Buying a Commercial licence. Commercial is sold through FastSpring, which acts as the reseller and merchant of record: you pay FastSpring, on FastSpring's own checkout page, and FastSpring takes the payment, issues the receipt and the invoice, and pays any refund. What you enter there — your card or other payment details included — is FastSpring's to handle, under its own privacy policy; your card number is never sent to us. When an order completes, FastSpring sends us a record of it: the buyer's name, email address and company, what was bought, what was paid, the order reference, and whatever else FastSpring puts in its record of an order. We keep that record as FastSpring sent it, with the subscription it paid for, and use it to set up the licence and the account it is managed from, and to act on a refund or a chargeback.

An order you start and do not finish. FastSpring's checkout has a box, not ticked unless you tick it, to receive updates from us. If you tick it, type your email address and leave without paying, FastSpring tells us the address, the name and country you entered, and what was in the cart, and we keep that as an enquiry, marked as an unfinished order. It is never added to the waitlist or to any announcement, and nothing is sent to it unless a member of our staff writes to you about the order you started. If you do not tick the box, we keep nothing that identifies you.

Renewing, quotes and your account at FastSpring. A renewal from the customer portal is a FastSpring order like any other: the portal opens FastSpring's checkout for you at the renewal price, and the order FastSpring sends us afterwards extends your licence. If we send you a quote, FastSpring holds it and takes its payment, and we see its state. The customer portal can also open your account at FastSpring, where your invoices, receipts and payment details are. To open it, we keep the id FastSpring gives your account and ask FastSpring for a link that signs you in; nothing in that account is copied to us.

6. Licence activation and refresh

A Community installation sends us nothing.

A commercial installation that was activated offline sends us nothing at runtime. The operator carries a signed request to the portal and carries the token back. The request is the customer’s to move; it is not an outbound call from the product.

A commercial installation activated online sends, at activation, exactly these nine fields and no others (LicenceActivationRequest):

• activationCode
• installationId
• installationPublicKey
• product
• productVersion
• edition
• platforms — the modules present in the image, not the brokers you connected
• nonce
• timestamp

A later refresh sends (LicenceRefreshRequest):

• licenceId
• installationId
• sequence
• nonce
• timestamp
• signature — by the installation key. There is no stored bearer secret anywhere

If the operator releases the installation — freeing the licence from a machine that is being rebuilt or decommissioned — the product sends one more call, with the same six fields as a refresh (LicenceDeactivationRequest):

• licenceId
• installationId
• sequence
• nonce
• timestamp
• signature — by the installation key, over a different domain prefix from a refresh, so one cannot be replayed as the other

That call is made only when somebody asks for it, and never on a schedule.

A rate limit may observe the caller address of those calls. That address is not part of the licence record, and it is not a picture of what you run.

We store the issued token, the installation it is bound to, the sequence, and the times that make a refresh inside the window return the same token. We do not store what the installation operates.

Registry credentials, when issued, are shown once and stored hashed. We do not keep the secret.

7. Support

A support request holds: who wrote (name and email), a subject, the messages in order, a reference, where it came from (portal, email, or imported), and a state (open, answered, closed). There is no priority field — a priority is an order of service, and an order of service is a promise nobody has made.

Files. A message can carry files — any type, up to 5 MB a file and 20 MB a request, yours and ours counted together. We keep each file in object storage at Hetzner, in Germany, under a name made from the request's reference and a random id rather than the name you gave it, and it stays with its request for as long as the request is kept (§11). Only your own organisation and our support staff can download one, and every upload and download is recorded in our staff audit. Nobody reads a file's contents, and nothing scans them. There is still no diagnostics bundle, and nothing here asks you for one. Whatever you paste or attach, treat it as visible to the people who answer support.

8. How we use what we hold

• To reply to an enquiry you submitted
• To write to the people on the Commercial waitlist, as their consent says, until they unsubscribe
• To run the account you were invited to, including signing you in and ending a session
• To issue, refresh, rebind or revoke a licence you are entitled to
• To set up the licence and the account an order paid for, to extend it when you renew, and to act on a refund or a chargeback
• To see who started an order at the checkout, agreed there to hear from us, and did not finish it
• To keep a staff audit of who did what on our side
• To apply a rate limit and to refuse a duplicate enquiry
• To meet a legal obligation that actually applies to us

We do not sell personal information. We do not use a lead to train a model. We do not put marketing cookies on the forms.

We send mail through Google Workspace, which §10 names. There are six kinds of message, and each one answers something you did:

• A password-reset link, when you ask for one. It works once and stops working an hour after it was sent.
• A note that a support request has been answered. It links to the thread rather than quoting the reply, because an answer can name a licence or an incident and a copy of it sitting in a mailbox is a copy outside §11.
• An invitation after a purchase, once you have bought a Commercial licence, if you do not yet have an account with a password. Its link sets one, and stops working fourteen days after it was sent.
• A confirmation link after you register a free account. It confirms the address and lets you choose a password, and stops working forty-eight hours after it was sent. If you did not register, ignore it: the account stays unusable.
• A reply to an enquiry you sent us through one of the site's forms, or about an order you started at FastSpring's checkout and did not finish, written by a member of our staff and sent from info@broka.dev. Unlike the support note it carries the reply's text, because an enquiry has no account to link to, and we keep a copy of the reply with your enquiry.
• An announcement to the Commercial waitlist — to the people who joined it and nobody else, because that is what they agreed to (“contact me when the Commercial edition opens”). Each person gets a copy of their own.

Unsubscribing from announcements. Every announcement has an unsubscribe link at its foot, which opens a page with a single button; where your mail program offers its own unsubscribe button, that works too, in one click. Once an address has unsubscribed it is never sent another announcement. A reply to an enquiry you sent still reaches it. An announcement carries no tracking pixel, and we count no opens and no clicks: the Broka mark is part of the message itself, so nothing is fetched when you open it.

The links in the reset, invitation and confirmation mails are credentials, so each is sent straight away rather than queued, and we keep only a hash of it. An invitation a member of staff creates by hand is still shown to them rather than mailed, and sending a form notifies nobody: the only mail a lead receives is a reply a person wrote, or an announcement if they joined the waitlist.

Notifications to our own staff are a queue on our side rather than mail to you. A row in it holds a subject and a reference and no body — deliberately, so that the table is not worth stealing.

9. The marketing site’s typefaces, visitor measurement and advertising

The marketing site serves its typefaces itself, from broka.dev: opening a page sends nothing to a font provider.

Google Analytics. The marketing site counts visits with Google Analytics. It sets cookies in your browser (_ga, _ga_…) and sends Google the pages you open, how you arrived, and your browser and device type, together with your address, which Google uses to estimate a country and a city and does not keep. If you visit from the European Union, the rest of the European Economic Area or the United Kingdom — or from somewhere the site cannot tell — nothing is loaded until you allow it. To decide whether to ask, the site reads the country Cloudflare attributes to your address; that is not stored. Elsewhere Google Analytics loads with the page. Either way you can change your choice at any time from Analytics choice in the footer, and a refusal is remembered in your browser. We use it to count visits and to see which pages lead to a download, a form or a purchase. It is not joined to a lead, an account or a licence, and Google keeps it for two months before deleting it.

Google Ads. We advertise Broka on Google Search. When you arrive by clicking one of those ads, the link carries an identifier Google added to it, and Google Analytics — under the same choice as above — reads it, so Google can tell us how many ad clicks led to a click on Download Community. That is the only thing reported back to the advertising account, as a count. The site loads no advertising tag of its own, and nothing it measures is used to show you ads elsewhere: our analytics are linked to Google Ads with personalised advertising switched off and with no audience lists shared.

Google Analytics runs on broka.dev only. The customer portal and the licence server do not load it.

10. Who else can see it

The vendor service — leads, portal accounts, licence rows — runs on a machine we operate in Nuremberg, Germany, on infrastructure provided by Hetzner Online GmbH. They see what a host sees. If that machine moves, this paragraph is updated in the same change. We will not hide a host behind “our cloud partners”.

The licence signing key is held on that same machine, in a signing engine we run ourselves. It is not with a third party, and no third party can use it.

Until 2026-09-11 the key sat in a cloud key vault and this paragraph named that provider. We withdrew that arrangement and the keys it held were destroyed with it, so the provider is no longer anyone who can see anything. We are saying so rather than deleting the sentence, because the change is not only a removal: the key and the records it signs for now sit on one machine instead of two, so what separates them is the engine's own policy rather than a different company. The engine holds the key and nothing else — no leads, no accounts, no licence rows — and it can only be asked to sign, never to hand the key over.

Five outside parties see anything at all, and it is worth naming what each one sees.

Cloudflare sits in front of every one of our hostnames: this site, the customer portal, the licence server and the registry the commercial images are pulled from. It terminates the connection at its edge, so it sees every request made to any of them — the address it came from, the path, and the request itself.

Hetzner hosts the machine everything runs on, in Germany, and the object storage that keeps the files attached to support requests (§7).

Google Workspace relays every mail §8 lists, and therefore sees the address each one went to and what was in it.

Google also receives what §9 describes when Google Analytics runs on the marketing site, including the ad-click counts §9 says reach our Google Ads account, and may process it in the United States. It does not see the forms, the portal or the licence server.

FastSpring sells Commercial licences as the reseller and merchant of record, so it sees everything you enter at its checkout — your payment details included, which do not reach us — and handles it under its own privacy policy. It sends us the record of an order that §5 describes. It does not see the forms, the portal or the licence server.

None of those five names is the licence-server hostname, and none of them is reached by anything running inside your own installation.

Staff with the matching permission can read a lead, a customer, a support request or a licence record. A customer token cannot address a staff endpoint; the keys differ, and a deployment that collapses them will not boot.

We share information if the law that applies to us requires it, or to defend a claim. We do not have, and will not build, a way to reach into your installation to satisfy such a request about your brokers — that data is not here.

11. How long we keep it

Default: ten years, still identifiable, unless you ask us otherwise. Lead submissions, customer accounts, organisation and licence records, the order records FastSpring sends us, support messages, and our staff audit of what we did on this service are kept for ten years from the last activity on that record, in identifiable form — not anonymised as a matter of course.

That default yields where the law that applies to the record says it must. We are established in Türkiye, so KVKK applies to what we hold. GDPR applies when we offer Broka to people in the EU or EEA; UK GDPR is a sibling, not the same act. A United States state privacy law (California’s is the one people usually mean) applies only when that law’s own residency and size tests are met — there is no single US federal privacy statute for this. Other countries have their own acts; we do not print a catalogue and call it complete.

Where any of those, or another law that applies to you, requires a shorter life or a deletion we cannot refuse, that law wins. Where a legal duty requires us to keep a row longer (a licence we issued, a tax or commercial book), that duty wins and we will say so rather than pretend the row is gone.

This is not the product’s own audit retention. That clock lives in the customer’s installation and is theirs to set.

Record	What we do
Lead submissions	Ten years from submission, unless you ask us to delete it and the law lets us
Customer accounts	Ten years from last sign-in or last change, unless you ask us to close the account and the law lets us
Sessions	A session stops working when it expires, when you sign out, or when the account is disabled. Its row remains, marked ended and with the reason — a record that the sign-in happened, not a second archive of what you did in it. It carries no address, user agent or location, and it follows the account record above
Organisation and licence records	Ten years from the last issuance, refresh, rebind or revocation on that licence. A token we minted is a record we may have to keep even after you ask
Support messages	Ten years from the last message, unless you ask us to delete them and the law lets us. Files attached to a request follow the request
Staff audit of our actions	Ten years. This trail is how we show who invited, who issued, who revoked. Erasing it on request would erase the proof
Invitation and registry-credential hashes	Until spent or replaced; then they follow the account or organisation row

We do not sell the clock down to a quiet anonymisation job. If a row is still here, it is still a person or an organisation we can name.

12. Your rights

You may ask us to see what we hold about you, correct it, delete it, restrict or object to our using it, or take a copy of it. A customer and a visitor who only sent a form have the same door.

We will honour that request. We do not refuse a deletion because your country was missing from a bullet list.

Which statute sits on a given request depends on who you are and what we did:

• KVKK — we are established in Türkiye; it applies to what we hold as controller.
• GDPR — when we offer Broka to people in the EU or EEA. A site that is merely reachable from Europe is not enough; selling there on purpose is.
• UK GDPR — when we offer Broka to people in the United Kingdom. It is not “GDPR” by another name.
• A United States state law — when that law’s own tests are met (residency, and often a revenue or volume threshold). There is no one US privacy act for this product.

This page is not a certificate. We are not in Türkiye’s Data Controllers’ Registry (VERBİS); the Board’s exemption for a controller under the employee and balance-sheet thresholds applies — that is an exemption from the register, not from the law. We have not appointed an EU representative (GDPR Art. 27) or a UK one, and we have not designated a data-protection officer. If a representative is appointed, it is named here. The rights above are what we will not refuse when the law that covers you names them.

Deletion is a request we expect. Write to hello@orchesta.io (the address the company site publishes). Say which address or account you mean. We will ask enough to know it is you — a stranger deleting your lead would be the cheap way to lose the record. We do not publish a number of days in which we will finish; a response-time promise is a support promise, and this service does not make those.

Where we cannot erase a row (a licence we issued, the staff trail of that issuance), we will say so and say what we can still do — stop using it for mail, stop it being a live account — rather than return “deleted” for a row that is still there.

If you want to complain about how we handled a request, use the supervisory authority under the law that applies to you. We will not name one authority as if it were the only one.

13. Changes

This policy is published at /privacy. A change updates that page and the date at the top. A material change to what we collect will not be made only in a comment.