Antideploy Privacy Policy

1. Who we are

Antilayers Private Limited operates antideploy.com. In this policy "we", "us" and "Antideploy" mean Antilayers Private Limited, and "you" means the person using the service.

Registered office: C/o Yogendra Kumar, Phase-2, Yamnotri Enclave, Dehradun City, Dehradun, Dehradun- 248001, Uttarakhand
CIN: U62099UT2026PTC021581
Contact: support@antideploy.com

2. What we collect

2.1 Account information

You sign in with GitHub, with Google, or with a one-time link we email to you. We never ask you for a password, and we do not store one.

GitHub. Your numeric GitHub user id, your username, your display name, your avatar image URL, and your email address where GitHub releases it. GitHub does not always release an email address, and the service works without one.
Google. Your Google account identifier, email address, name and profile picture. The permission we request is exactly openid email profile. We do not request access to Gmail, Drive, Calendar, Contacts, or anything else in your Google account.
Email link. Your email address. When you ask for a sign-in link we record the address, when the link was requested and used, and the IP address it was requested from, so we can limit how many links are sent. We store only a hash of the link itself, so our records cannot be used to sign in.

2.2 Your code and files

Repositories. Signing in with GitHub does not give us access to your code. Access comes only from installing the Antideploy GitHub App and choosing which repositories it may see. We read the contents of those repositories in order to build and deploy them.
Uploaded folders. If you upload a folder, or your agent pushes one through our API, we store its files so the deployment can be built and rebuilt.

2.3 Environment variables and secrets

Values you save as secrets are encrypted before they are written to our database, using AES-256-GCM. They are decrypted only when a deployment runs and needs them. The console shows you which keys exist, never their values.

2.4 Deployment records and logs

We record what was deployed, when, whether it succeeded, and how long it took. We hold the build output and the runtime logs of your applications, because those are the things you need when a deploy fails.

2.5 Databases we provision

When you ask for a Postgres database we create one with our infrastructure provider and give you its connection details. What you store in that database is yours. We do not read it, and we do not analyse it.

2.6 Billing

Payments are taken by Razorpay. We never see, receive or store your card number, UPI ID, bank details, CVV or any payment credential. Those go directly to Razorpay. What we keep is the subscription identifier Razorpay gives us, which plan it is for, its status, the date the paid period ends, and the notification messages Razorpay sends us about it.

If you add money to the AI wallet, we keep the amount, the payment link Razorpay created for it, whether it was paid, and a running record of what your AI keys have spent.

2.6A Business accounts

If you start the Business plan from antideploy.com/business, we also keep:

What you tell us about the business: your name, your role, the business's name and website, and roughly how many people are on the team.
Your organisation: its name and who belongs to it, with each person's role. Everyone in an organisation can see the others' names, email addresses and roles, and its owners can see what each person's applications cost.
Invitations: when an owner invites someone, we keep the address invited, who invited them and when, and send that address one email with the link. We keep only a one-way hash of the link's secret, and the link works once, for seven days.
Credit and usage: each top-up (its amount, the payment link Razorpay created for it, whether it was paid, when it expires and who added it), and what each of the organisation's applications used each day and was charged, with the client name you gave the application, if any.
For measuring adverts: if you arrived from a Meta advert, the advert's click identifier and the Meta pixel's browser identifier from the cookies in section 4, and the browser you signed up in. They are used only to tell Meta which advert led to the business's first credit (section 3).

2.7 Preventing abuse

Antideploy runs code that anyone can deploy, so we check for the uses our Terms of Service prohibit, such as cryptocurrency mining.

Before a build. We automatically scan the files that say what gets built and run (Dockerfiles, compose files, Procfiles and start scripts) and the names of the files you deploy. This is automated pattern matching on those files, not a person reading your code.
While an application runs. We read its processor usage from our hosting providers' metrics. We do not look inside the application to do this.
If an account is suspended for abuse, we keep its GitHub user id, Google account identifier and email address on a blocklist so it cannot simply sign up again, together with a record of what happened.

2.8 AI API keys

AI API keys are issued by OpenRouter on our account. For each key you create we keep its name, the last four characters of the key, OpenRouter's identifier for it, and how much it has spent. The full key is shown to you once and never stored by us.

We do not see what your applications ask the AI models, or what they answer. Your application sends those requests to OpenRouter directly, not through us. OpenRouter reports only how much each key has spent.

2.9 Previews published from ChatGPT

If you publish a website through the Antideploy plugin in ChatGPT without an account, this is what we receive and keep.

The site's files. Kept for 24 hours and then deleted with the site, unless someone claims it. A claimed site becomes an application in that person's account and is treated like any other (section 7).
An anonymous identifier from ChatGPT. ChatGPT sends us an identifier that OpenAI makes up for each user, and it does not reveal your name or email. We do not store it as received. We keep a one-way keyed hash of it, with the time the preview was made and when it ends, so that we can limit how many previews one person can make in a day and count how many are made and kept. That record is kept after the site is deleted. It holds no files, and we cannot work out who you are from it.
The claim link. We keep only a hash of its secret, so our records cannot be used to claim a site. When someone claims a preview, we link the site to the account that claimed it.
What we do not receive. Your name, your email address and your ChatGPT conversation. OpenAI handles that conversation under its own terms and privacy policy, and we receive only what the plugin sends us. As with any request to our servers, the logs of our hosting providers record technical details such as the time and the address the request came from, and are kept as section 7 says.
Abuse checks. The automated checks in 2.7 run on every preview, and every page of a preview carries a notice saying it is an anonymous preview and how to report it.
Your choices. You do not need an account to publish a preview. To have one deleted before its 24 hours are up, write to support@antideploy.com with its address. The companies that run the site while it exists are listed in section 5.

3. What we do not collect

This is a short list and we intend to keep it short.

No analytics product. No Google Analytics, no Plausible, no PostHog, no Mixpanel, nothing of that kind. We do not record which pages you read, in what order, or how long you stayed.
No session recording and no heatmaps.
We do not sell your personal data, and we do not share it with data brokers.

One exception, and it is an advertising one. The public pages carry the Meta (Facebook) pixel, so that we can tell how many of the people who see an advert for Antideploy go on to open an account. It reports three things to Meta: that a page here was viewed, that an account was created, and, for a business account, that its first credit was added and how much. That last one is also sent from our own server, with the advert's click identifier, the pixel's browser identifier and the browser the account was opened in, so that it is counted when the pixel is blocked; never your email address. Apart from those two moments the pixel is not on any page inside your account, and nothing about your applications, your code, your logs or any other payment ever reaches Meta. Section 4 lists the cookies involved, and who is not given them at all.

4. Cookies

Six of these are ours. The last two belong to the Meta pixel described in section 3. Those two, and our ad_signup, ad_purchase and ad_fbc, exist only to measure adverts, and they are the only cookies on this site that are not strictly necessary.

There is no consent banner, and the pixel is switched off instead of asked about. It does not load at all for visitors in the European Economic Area, the United Kingdom or Switzerland, where consent would have to be collected first, so nobody there is given an advertising cookie to refuse. Everywhere else it loads without asking. You can block it with any content blocker or in your browser's settings, and nothing on this site will stop working if you do.

Cookie Purpose Lifetime

__Host-ad_session Keeps you signed in. HttpOnly, Secure, SameSite Lax, so it cannot be read by JavaScript and cannot be set by any other subdomain. 30 days

ad_oauth_state Protects the sign-in round trip against cross-site request forgery. Minutes, during sign-in only

ad_src Records where you first arrived from, so we can tell which of the places we write actually bring people here. A short label such as a referring site's hostname or a campaign name, written once on your first visit. Never a full address and never a search query. 30 days

ad_signup Marks a sign-in that has just created an account, so that it is reported to Meta once and not twice. A random value with nothing in it that identifies you. 5 minutes

ad_purchase Marks the moment a business's first credit has been added, so that it is reported to Meta once and not twice. Holds that top-up's reference and amount. Not set for visitors in the EEA, the UK or Switzerland. 5 minutes

ad_fbc Set only if you arrived from a Meta advert: which advert it was, the same thing the pixel's _fbc records, kept by us so that a business's first credit can be matched to it when the pixel is blocked. Not set for visitors in the EEA, the UK or Switzerland. 3 months

_fbp Set by the Meta pixel to recognise the same browser across visits. Not set at all for visitors in the EEA, the UK or Switzerland. 3 months

_fbc Set by the Meta pixel only if you arrived from a Meta advert, to record which one. Same exclusions as above. 3 months

Cookie	Purpose	Lifetime
`__Host-ad_session`	Keeps you signed in. HttpOnly, Secure, SameSite Lax, so it cannot be read by JavaScript and cannot be set by any other subdomain.	30 days
`ad_oauth_state`	Protects the sign-in round trip against cross-site request forgery.	Minutes, during sign-in only
`ad_src`	Records where you first arrived from, so we can tell which of the places we write actually bring people here. A short label such as a referring site's hostname or a campaign name, written once on your first visit. Never a full address and never a search query.	30 days
`ad_signup`	Marks a sign-in that has just created an account, so that it is reported to Meta once and not twice. A random value with nothing in it that identifies you.	5 minutes
`ad_purchase`	Marks the moment a business's first credit has been added, so that it is reported to Meta once and not twice. Holds that top-up's reference and amount. Not set for visitors in the EEA, the UK or Switzerland.	5 minutes
`ad_fbc`	Set only if you arrived from a Meta advert: which advert it was, the same thing the pixel's `_fbc` records, kept by us so that a business's first credit can be matched to it when the pixel is blocked. Not set for visitors in the EEA, the UK or Switzerland.	3 months
`_fbp`	Set by the Meta pixel to recognise the same browser across visits. Not set at all for visitors in the EEA, the UK or Switzerland.	3 months
`_fbc`	Set by the Meta pixel only if you arrived from a Meta advert, to record which one. Same exclusions as above.	3 months

5. Who else sees it

Running this service means other companies process some of your data on our behalf. This is the complete list.

Provider	What it does	What it can see
Google Cloud Platform	Builds and runs applications on our main hosting, and holds the files and logs of applications deployed there	Your code, your files, your logs
Fly.io	Builds and runs applications on our second hosting, which we use when our main hosting is unavailable	Your code, your files, your logs
Railway	Runs the Antideploy platform itself, and stores the folders you upload or push	Account records as the platform uses them, and your uploaded files
Neon	Hosts our database and the Postgres databases we provision for you	Account records, and the contents of your database
Cloudflare	DNS and the edge proxy in front of the platform and your deployed applications	Request metadata, including IP addresses
Resend	Sends transactional email, such as a failed deploy notice or a sign-in link. Resend delivers through Amazon SES	Your email address and the message
Razorpay	Takes payments, including AI wallet top-ups	Your payment details, which we never see
OpenRouter	Issues the AI API keys you create, and receives the AI requests your applications send with them	What your applications send to AI models, and how much each key spends
GitHub	Sign-in, and repository access where you have installed our App	Your identity and the repositories you selected
Google	Sign-in with Google	Your identity
Meta	The advertising pixel on the public pages, and the report of a business's first credit, described in section 3	That a page here was viewed, that an account was created, or that a business added its first credit and how much, together with your IP address and browser details, and the advert identifiers in section 4

Provider

What it does

What it can see

Google Cloud Platform

Builds and runs applications on our main hosting, and holds the files and logs of applications deployed there

Your code, your files, your logs

Fly.io

Builds and runs applications on our second hosting, which we use when our main hosting is unavailable

Your code, your files, your logs

Railway

Runs the Antideploy platform itself, and stores the folders you upload or push

Account records as the platform uses them, and your uploaded files

Neon

Hosts our database and the Postgres databases we provision for you

Account records, and the contents of your database

Cloudflare

DNS and the edge proxy in front of the platform and your deployed applications

Request metadata, including IP addresses

Resend

Sends transactional email, such as a failed deploy notice or a sign-in link. Resend delivers through Amazon SES

Your email address and the message

Razorpay

Takes payments, including AI wallet top-ups

Your payment details, which we never see

OpenRouter

Issues the AI API keys you create, and receives the AI requests your applications send with them

What your applications send to AI models, and how much each key spends

GitHub

Sign-in, and repository access where you have installed our App

Your identity and the repositories you selected

Google

Sign-in with Google

Your identity

6. Where it is kept

Applications, builds and logs are held either in Google Cloud's asia-southeast1 region or with Fly.io in its sin region, both in Singapore. If Fly.io has no room in Singapore when an application starts, it may run that application in Mumbai, Tokyo or Sydney instead.
The Antideploy platform, and the folders you upload or push, are held with Railway in Singapore.
Our database, and the databases we provision for you, are held with Neon in aws-ap-southeast-1, also in Singapore.
Cloudflare operates a global network, so request metadata may be handled at an edge location near you.
OpenRouter passes the AI requests your applications make to the model provider they choose, which may be outside India and outside Singapore.

If you are in India, this means your data is processed outside India. By using the service you agree to that transfer.

7. How long we keep it

Your account is kept until you ask us to delete it.
An application you delete is removed properly. We delete the running service, the database we provisioned for it, the files we stored for it, and its records in our database. This is a real deletion, not a hidden flag.
Logs are held for 30 days and then deleted automatically.
A preview nobody claims is deleted 24 hours after it was made, with its files. The record that it existed, which holds no files and only a hash of ChatGPT's anonymous identifier, is kept.
Billing records, including AI wallet top-ups and spending, and Business credit top-ups and the daily usage charged against them, are kept for as long as Indian tax and company law requires us to keep our books of account, which is currently eight financial years.
Sign-in link records are kept for as long as they are needed to limit abuse of sign-in.
Records of abuse, meaning the blocklist entries and the record of what happened, are kept for as long as they are needed to protect the platform and meet our legal obligations, even after the account itself has been deleted.

8. Your rights

Under India's Digital Personal Data Protection Act, 2023, you may ask us to:

tell you what personal data of yours we hold and who we have shared it with,
correct or complete anything that is wrong or out of date,
erase your personal data where we no longer need it,
nominate someone to exercise these rights if you die or become incapacitated,
raise a grievance about how we have handled any of this.

Deleting your account. Go to Settings, then Account, and choose "Delete account". We cancel any subscription, delete your applications, their databases, files and images, your keys, tokens and sign-in records, and where we can we remove the Antideploy GitHub App from your GitHub account. We email you when it is done. It takes a few minutes and cannot be undone. We keep only what tax law obliges us to keep, which is billing records if you have ever paid us, and even then your name, handle, email address and sign-in details are removed. If you cannot sign in, email support@antideploy.com from the address on your account and we will do it for you.

9. Grievance Officer

If something about your data has gone wrong, this is the named person responsible for answering you.

Akkshatt Shah, CEO
Antilayers Private Limited
C/o Yogendra Kumar, Phase-2, Yamnotri Enclave, Dehradun City, Dehradun, Dehradun- 248001, Uttarakhand
support@antideploy.com

We will acknowledge your grievance and respond within thirty days.

10. Security

What we actually do:

Everything is served over HTTPS.
Secrets you store are encrypted at rest with AES-256-GCM.
The session cookie is HttpOnly, Secure, and carries the __Host- prefix, so an application deployed on a neighbouring subdomain cannot set or read it.
Secret values are never written to logs and never sent to a browser.
Payment credentials never reach our systems at all.
Sign-in links work once and expire after 15 minutes, and we store only a hash of each.

No service can promise that nothing will ever go wrong, and we will not pretend otherwise. If a breach affects your personal data we will tell you and the Data Protection Board as the law requires.

11. Children

Antideploy is not intended for anyone under 18. We do not knowingly collect personal data from children. If you believe a child has given us personal data, email us and we will delete it.

12. Changes to this policy

If we change this policy we will update the date at the top of the page. If a change materially affects how we handle your personal data, we will email account holders before it takes effect.

13. Contact

Antilayers Private Limited
C/o Yogendra Kumar, Phase-2, Yamnotri Enclave, Dehradun City, Dehradun, Dehradun- 248001, Uttarakhand
support@antideploy.com

Our Terms of Service cover the commercial side of using Antideploy.

What we collect, and who else sees it.