Privacy Policy
Last updated 25 September 2026
What Outpost Is
Outpost is a private social posting relay operated by Jay Digital. It holds connections to the operator's own social media accounts and publishes content that the operator's own applications send to it. It is a single operator tool, not a public service, and it does not offer accounts to the general public.
What This App Collects
- Account details: the operator email address and a hashed password. Passwords are never stored in readable form.
- Session records: a hashed session token and its expiry date.
- Connected platform data: for each connected social account, the platform account identifier, display name, handle, avatar image URL, granted permissions, and the access and refresh tokens the platform issues.
- Post records: the text, media addresses, scheduled times, per platform outcomes, resulting post identifiers and links, and any error a platform returns.
- Uploaded media: image and video files sent to the API for publishing, stored on the server that runs this instance.
- Notification tray messages: short records the dashboard shows the operator about connections and posts. One about a connected account names that account, and one about a post carries the opening of its text. They stay until a deletion request removes the account they name, or until the instance data is erased.
- API keys: a one way hash of each key, plus its name and first characters.
- Platform app credentials: the application identifier and secret the operator enters for each platform, kept as a single encrypted value and never shown back in the dashboard once saved.
- Operator notes: free text the operator types into the dashboard scratchpad.
- Deletion receipts: for each data deletion request Meta sends, a random confirmation code, the platform name, the internal identifiers of the records that were removed, and the times the request arrived and finished.
- Server logs: ordinary web server request logs.
What This App Does Not Collect
No analytics, no advertising or tracking pixels, no third party scripts, no measurement cookies, no location data, no contact lists, and no browsing history. Outpost gathers no information about anyone other than its operator and the content that operator chooses to publish.
Cookies
Three first party cookies, all httpOnly and none used for advertising or measurement: a session cookie that keeps the operator signed in, a short lived cookie holding the answer check for the sign in security image, and a short lived cookie carrying the state value during a platform connection.
How Platform Data Is Used
Data received from a social platform is used for exactly two purposes: publishing content the operator sends, and showing the operator which account is connected. Platform data is never sold, rented, used to build profiles of any person, used for advertising, or used to train machine learning models. It goes to no third party, with the single exception described in the next paragraph. Content is transmitted only to the platforms named in each request, using the operator's own credentials, and access tokens are encrypted at rest and never displayed, logged, or exported.
One optional feature sends a line off this server. If the operator sets a topic name for phone alerts, a connection that stops working posts a short message to ntfy.sh, a free notification service, or to another notification server the operator names instead. That message says which platform needs reconnecting and nothing else: no display name, no handle, no token, no post content, and no account identifier. A topic on that service can be read by anyone who knows its name, which is why the message carries none of those things. With no topic name set, nothing is sent and the alert appears on the dashboard alone.
Google and YouTube API Services
When the operator connects a YouTube channel, Outpost uses the YouTube Data API and Google OAuth. Its use of information received from Google APIs follows the Google API Services User Data Policy, including the Limited Use requirements. Google account data is used only to provide the feature the operator connected it for, and for nothing else.
With the operator's consent, Outpost requests two YouTube scopes, and only for the operator's own channel:
- youtube.upload: to upload the videos the operator sends through Outpost to the connected YouTube channel.
- youtube.readonly: to read the connected channel identity, meaning its id, name, and picture, so the dashboard can confirm which channel is connected and check that the connection still works.
From Google, Outpost stores the channel id, name, and avatar image URL to show the connected account, the OAuth access and refresh tokens encrypted at rest, and a record of each uploaded video, meaning its title, description, and the resulting video id. This data is used only to upload the operator's videos to the connected channel and to keep the connection working. As stated above, it is never sold, shared with any third party, used for advertising, used to build profiles of any person, or used to train machine learning models.
The operator can disconnect YouTube on the Accounts page, which deletes the stored tokens and channel details, and can revoke Outpost's access at any time from Google Account security settings. The data deletion page explains how to request erasure of any data that remains.
Where Data Lives
On a single server controlled by the operator, currently a virtual machine hosted in Phoenix, United States. Nothing is stored anywhere else: no third party database, no analytics provider, no cloud storage vendor. The only platform data that leaves this server, other than what is sent back to the platform it came from, is the line in the phone alert described above, and only when the operator has set a topic name for it. Traffic between a browser or an application and this server is encrypted with HTTPS.
Retention and Deletion
Data stays until it is deleted. Disconnecting a social account revokes the token at the platform where that platform supports revocation, destroys the stored copy immediately, and clears the display name, handle, avatar image link, and platform details from the record. Two identifiers stay: the internal one that links past posts to the record, and the platform's own account identifier, which is what lets a later reconnection update the same record instead of creating a second one. Messages already in the notification tray still name the account after a disconnect, and are removed by a deletion request or by erasing the instance data. Deleting the instance data directory erases everything: accounts, tokens, posts, uploads, notifications, and keys.
Access can also be revoked at any time from the social platform's own settings, which stops this app from posting. Facebook, Instagram, and Threads tell this instance when that happens: Meta posts a signed notice naming the person who removed the app, and every connection recorded here against that person is taken out of service as soon as the notice arrives, in the same state a disconnect leaves it, with the tokens destroyed and the identifying fields cleared. A notice naming a person this instance holds no connection for changes nothing. The operator is told on the dashboard, so the account can be connected again if the removal was not intended. The other platforms send no such notice, so a connection revoked there stops working, the connection check that runs every six hours marks it as needing reconnection, and what is stored here is cleared by disconnecting it.
Deletion Requests Through Meta
Facebook, Instagram, and Threads let a person ask, from their own Meta settings, for the data an app holds about them to be deleted. Meta signs that request with the app secret, and this instance checks the signature before it reads or changes anything. A request that does not verify is refused and deletes nothing. So is one that verifies against more than one of the app secrets saved here, because the app it came from cannot then be established, and Meta sends it again once the operator corrects the secrets.
A request that verifies deletes the connected account record for the person it names: the platform account identifier, display name, handle, avatar image link, granted permissions, and the encrypted access and refresh tokens. The delivery records for that account go with it, meaning which content was sent to the account, the resulting post identifiers, and the links to those posts. Messages in the operator's notification tray that name the account are deleted in the same step. On Facebook, each Page connection is recorded against the person whose login created it, so a request removes the Pages recorded against the person who signed it.
What survives is what does not name the account. The operator's own material stays: the text they wrote, the media they attached, and the times they scheduled. Tray messages that never named the account stay, such as a note that a post reached three platforms. The receipt described below stays, so this instance can still answer for the request afterwards. Content already published on a platform is outside this instance, and only that platform can remove it.
One case is worth stating plainly. A request is matched on the identifier Meta signs it with, so a Facebook Page connected before this instance began recording the identifier of the person who connected it has nothing to match, and a request naming that person leaves it in place. Connecting the Page again records the identifier and brings it under the same matching. Writing to the address below removes it either way.
Each request leaves a receipt so it can be checked afterwards: a random confirmation code, the platform name, the internal identifiers of the records that were removed, and the times the request arrived and finished. The receipt holds no name, handle, token, or platform account identifier, and the identifiers in it point at records that no longer exist. Meta shows the confirmation code to the person who asked, and that code can be entered on the Data Deletion Status page at any time to see what was removed and when.
To request deletion of anything else held by this instance, write to privacy@jaydigital.us.
Security
Platform tokens are encrypted at rest with AES-256-GCM. Passwords are hashed with scrypt. API keys are stored only as hashes. Sessions use httpOnly cookies. Connections are checked automatically every six hours so a credential that stops working is noticed rather than left in place. No system is perfect, and this policy makes no guarantee of absolute security.
Children
Outpost is not directed at children and holds no accounts for anyone under 13.
Changes
Any change to this policy is published on this page with a new date at the top.
Contact
Jay Digital, reachable at privacy@jaydigital.us. The companion Terms of Use covers how this instance may be used.