Privacy Policy

Energixer is a video hosting and processing service: developers send us video through an API, we store and transcode it, and we serve it back for playback. This policy says what that means for personal data — in the specific terms of how this service is actually built, not in general ones.

Two different relationships, and it matters which one you are in.

• Videos our customers send us. We are a processor. The customer (the "domain" holding the API key) decides what is uploaded and why; we store, transcode and deliver it on their instructions. If your video reached us through somebody's app, they are the controller and their privacy policy — not this one — governs it. We will help them answer you, but they have to ask.
• Console accounts, the sandbox, and this website. We are the controller, and everything below applies directly.

What we store, and why

Videos and their metadata

For every video: the file itself, its declared content type and size, and what ffprobe measures — duration, width, height. We also store two free-text fields the uploading customer chooses, uploader_ref and external_ref. Those may contain the customer's own user identifiers; we treat them as opaque and never try to resolve them to a person.

A customer can also mark videos private and issue a playback key to each of their end users. Those keys carry a third free-text field the customer chooses, viewer_ref, under the same rule: it may hold their own identifier for the person watching, we treat it as opaque, and we never try to resolve it. The keys themselves are not stored — they are signed and verified, never written down. We store a viewer_ref only when a customer explicitly revokes one, so that we can refuse that viewer's outstanding keys, and those revocation records are deleted automatically once they are a day old.

We do not log which viewer watched which video, and we do not build viewing histories.

We do not analyse video content by default. Optional transcripts and moderation frames are off unless somebody asks for them — a customer can turn either on for a whole domain, and a transcript can also be asked for one video at a time on the call that starts the upload. Either way the processing happens on that instruction, never on ours.

Transcripts, when you ask for one

If a transcript is requested, the machine that encodes the video also runs speech recognition on its audio and produces a text transcript and a subtitle file, which are stored with the video's other outputs and deleted with them.

The audio never leaves that machine. Speech recognition runs as a local program on the worker — the same worker described below — using a model file shipped inside its image. There is no speech-to-text API, no third-party transcription vendor, and no account with one. This is the same promise as the rest of this page: the list under "Who else is involved" is complete.

Two consequences worth stating plainly. A transcript is a text copy of everything said in the video, so it is personal data whenever the speech is — and if the video is encoded on a rented burst machine (below), the transcription happens there too. And the subtitle file is served from the same unguessable-but-public URL as the video itself.

Who runs the machines that encode your video

Every worker on this service is run by me, on machines I control. No third party has ever been issued a worker credential, and none is going to be without this page changing first.

The reason to say that explicitly: Energixer's workers are ordinary HTTP clients that pull jobs from an instance-wide queue, so a worker is not scoped to one customer — the software would let me hand somebody else a credential and let their machine decode your video. I don't, and if that ever changes, this section is where you will read about it before it happens.

Some of those machines are rented. When more videos arrive at once than my own machines can encode, extra workers start automatically on servers I rent from Amazon Web Services and Microsoft Azure, and they stop again when the backlog clears. I run them, I hold the only credentials they use, and they run the same software as every other worker — but the hardware belongs to those companies, and while a video is being encoded it is on their infrastructure. Both are US companies, so this can involve an international transfer of the video and its filename. Nothing is stored there: a burst worker downloads the video, encodes it, sends the results back and is destroyed.

Private by default; public videos are unguessable, not private

Finished videos are private unless the customer marks them public. A private video is served only to a request carrying a playback key the customer issued, and those keys expire.

A video the customer marks public is served from a URL containing a random UUID with no authentication. For those, the URL is the capability: anyone who has it can watch, and anyone you send it to can pass it on. Treat a public playback URL like a password — do not put it in public places you would not put the video itself. Note also that a public video that is later made private may stay reachable through caches for up to a day.

Keys and secrets

API keys (ek_…), webhook signing secrets and worker service-account secrets are stored only as SHA-256 hashes, alongside the last four characters of an API key so you can tell your own keys apart. Nobody — including the operator — can read your key back out of the system; that is why rotation shows a new key exactly once. A rotated key keeps working for one hour so you can redeploy without an outage.

Console accounts

If you sign in to the console, we receive from Google only the openid email profile basics: a stable account identifier, your email address and whether Google says it is verified, your display name and your avatar URL. We store those, plus your role, a session counter used to sign you out everywhere, and when you last signed in.

Your identity here is the pair (provider, account identifier). Your email address is a stored attribute, never the key we match you on — so an address changing hands elsewhere can never hand somebody your account.

Every change you make in the console — rotating a key, changing a quota, minting a worker account, assigning a member — is written to an audit log with your account attached. That log exists so the operator can answer "who did this", and it is kept for as long as the instance runs.

IP addresses

Two places, both narrow:

• The sandbox stores the IP a throwaway session was created from, to enforce its per-IP daily budget. It is deleted with the session at the 24-hour purge.
• Rate limiting stores counters keyed by IP (or by credential, where there is one). Each row carries an expiry and is swept after its window closes.

Webhooks

If you configure a webhook, we store each delivery: the event payload, the number of attempts, and the last response status — so that a failed delivery can be retried and replayed. Payloads describe the video, not its content.

Logs

Ordinary operational logs: requests, errors, job outcomes. They are what makes an outage diagnosable.

The sandbox

The demo mints a throwaway key with no signup. Everything in it is temporary and public-ish by design: uploads are watermarked, limited to three videos a day per IP, served from the same unguessable-but-public URLs as everything else, and purged entirely after 24 hours along with the session. Do not put anything private in the sandbox.

The demo has a transcript checkbox, and it is unchecked. Nothing you upload to the sandbox is transcribed unless you tick it, per upload — we are not going to run speech recognition on a stranger's video because a default said so. Tick it and the transcript is produced as described above, shown to you, and purged with everything else at 24 hours.

Cookies and tracking

One cookie: ex_console. It holds your console session, is httpOnly, SameSite=Lax, Secure on HTTPS origins, lasts 14 days, and can be invalidated everywhere by signing out of all devices. There is no other cookie, no local storage of personal data on the marketing pages, and no cookie banner because there is nothing to consent to.

No analytics, no advertising, no third-party scripts, no third-party fonts. Every asset on every page is served from this origin — and that is not a promise we ask you to take on trust: an automated test fails the build if any published page loads an external resource.

Who else is involved

The complete list:

• Google, if Google sign-in is enabled for the console — and only for sign-in. Google is a US company, so signing in involves an international transfer of the identity data described above.
• Amazon Web Services and Microsoft Azure, as infrastructure for burst encoding capacity — see "Who runs the machines that encode your video" above. They provide the servers; the workers on them are mine. Both are US companies.
• Nobody else. No analytics vendor, no CDN, no transcoding service, no speech-to-text service, no third-party worker.
• The hosting providers running the servers.

That is all. Playback, the demo, the console and these documents call no other service.

How long we keep things

• Raw uploads are deleted once processing finishes. This is deliberate and has a consequence worth knowing: after the raw file is gone, re-encoding a video requires uploading it again.
• Deleted videos are marked deleted immediately — they stop being served — and their files are reaped shortly afterwards by a background job.
• Sandbox sessions, videos and artifacts: 24 hours, then purged.
• Rate-limit rows: until their window expires.
• Database backups: nightly, kept 14 days, copied off the machine. So deleting something removes it from the live service immediately, but a copy can persist in backups for up to two weeks.

Your choices

• Delete a video through the API or the console, at any time.
• Rotate or revoke an API key, a webhook secret or a worker account.
• Sign out everywhere from the console, which invalidates every existing session for your account.
• Account deletion, data export, or any other request: email us. There is no self-serve endpoint for it, and we would rather say so than describe a button that does not exist.

Depending on where you live you may have rights to access, correct, delete, port or object to processing of your personal data. If your video went through a customer's app, ask them first — they are the controller and they can act on it directly through the API. Otherwise, email us and we will answer.

Children

This service is for developers building applications. It is not directed at children, and we do not knowingly create console accounts for anyone under 16.

Changes

We will update this page when the service changes, and the date at the bottom with it. Material changes to how we handle personal data will be announced to account holders by email.

Who I am, and how to reach me

Energixer is a personal project run by one person. There is no company behind it, no support desk, and no commercial relationship — just an inbox.

Questions about this policy, or any request about your data: [email protected].

Energixer is a personal project run by one person — there is no company behind it. Questions about this document, or any request about your data: [email protected].

Last updated 3 August 2026.