Skip to content

Publish a file

Eidos Publish turns a local .eidos, .md, or .markdown file into a stable hosted URL. Changed content creates and activates an immutable Version for one resource slug; an unchanged Source Bundle reuses the active Version. Eidos Files use the read-only Eidos Runtime; Markdown is rendered once into a script-free static page. Your local file remains the source of truth and the CLI can exit after publishing.

  1. Sign in to the Publish account page.
  2. Create a Publish CLI key and copy it when it is shown. The service keeps only its hash, so the same key cannot be displayed again.
  3. Store the key as EIDOS_PUBLISH_TOKEN in your current shell or secret manager. Do not pass it in a shared script or commit it to a repository.
  4. Confirm that your CLI build includes the Publish command:
Terminal window
eidos publish --help

Choose a slug for this resource and publish the file:

Terminal window
eidos publish tracker.eidos --slug tracker

The slug becomes the URL path. It contains 1–64 lowercase letters, digits, or hyphens, and must start and end with a letter or digit. For example, the command above can produce a URL such as:

https://u-….eidos.ink/tracker

Publish can replace the opaque host with an independent Publish handle. Open the Publish account page, enter a compatible handle under Publish domain, and select Claim domain. The service claims handle.eidos.ink immediately; the assigned u-* hostname remains a stable fallback. The handle does not change your account username. Handles contain 3–30 lowercase letters, digits, or hyphens, start with a letter, and cannot use reserved Publish or Relay namespaces.

The normal terminal output shows progress while the CLI validates the file, discovers local attachments, hashes and deduplicates source objects, uploads the pending bytes, prepares the serving target, and activates the Version. The command returns only after the Version is ready and active, or exits nonzero with an error. The CLI fingerprints the complete canonical Source Bundle, including attachment digests. Repeating the command with identical content verifies the active fingerprint and does not create redundant Version history.

To link directly to a table or view in the published file, append its stable Eidos UUIDv7 IDs:

https://u-….eidos.ink/tracker?table={table-id}&view={view-id}

The view parameter can be used by itself. Unknown IDs fall back to the default table and view.

An Eidos File can contain a Form View that writes new rows into one of its Tables. Publish that view as a hosted form by its stable View ID or name:

Terminal window
eidos publish feedback.eidos --slug feedback --form-view "Public feedback"

The command publishes a new immutable Form revision. Visitors see only the fields selected by that Form View; internal File, Table, View, and Field IDs are not exposed in the browser definition. Public, password, and account-private access use the same options as other Publish resources.

Form response access is configured separately from resource access. Require an eidos.space account with --form-respondents signed-in. Add --one-response-per-user when each signed-in account may submit only once:

Terminal window
eidos publish feedback.eidos --slug feedback \
--form-view "Public feedback" \
--form-respondents signed-in \
--one-response-per-user

Anonymous forms always allow multiple responses because Publish cannot reliably identify a person without an account. Changing these controls does not create a new content Version when the Form definition is unchanged.

Completed responses wait in a private Publish Inbox. They do not modify the hosted snapshot or a cloud copy of your dataset. Pull them into the original local file with the Publication ID returned by the publish command:

Terminal window
eidos collect feedback.eidos \
--publication 7300a083-df92-49d8-945d-1e0bae0eac18

Each response is imported through the Eidos Runtime. The new Row and a local import receipt are committed in one SQLite transaction, then the cloud response is acknowledged. Retrying after a crash or lost acknowledgement does not create a duplicate Row.

File fields are supported. Submitted attachments are downloaded, verified by size and SHA-256, and stored beneath the source directory in .eidos-assets/publish/sha256/. Identical attachment bytes reuse one local content-addressed file.

The published Form does not change automatically when the local schema changes. Republish explicitly to activate a new revision. The current preview collector stops with a schema error if the Table or Form View has changed since that revision; this prevents silent field loss or unsafe conversion.

Publish Markdown with the same command and slug model:

Terminal window
eidos publish docs/guide.md --slug guide

Markdown uses CommonMark with GitHub-style tables, strikethrough, task lists, and autolinks. The document must be UTF-8 and at most 16 MiB. Raw HTML is displayed as text rather than executed, no page JavaScript is allowed, and the published page receives a restrictive Content Security Policy.

Relative link and image destinations become attachments:

![Architecture](assets/architecture.png)
[Download the workbook](files/example.xlsx)

The paths are resolved from the Markdown file’s directory, uploaded with the Version, and rewritten to immutable Version-bound URLs. https:, mailto:, inline image data:, and #fragment destinations are not uploaded. Unsafe link protocols are removed by the renderer. Absolute paths, other URL schemes, query-bearing local paths, escaping paths, and symlinks are rejected before activation.

For Eidos Files, relative File-field entries are attachments. For Markdown, relative link and image destinations are attachments. The CLI resolves them from the source file’s directory, verifies that each path is an ordinary file without symlink components, and uploads it with the source snapshot. Eidos File entries also have their declared byte count checked exactly.

Objects with the same SHA-256 are uploaded and stored once per account, even when several File entries, paths, slugs, or Versions reference those bytes. Published attachments use the same public, password, or private authorization as their resource. Missing files, changed sizes, escaping paths, symlinks, and attachments larger than 1 GiB fail the publish before activation. Standard Publish accepts an .eidos entrypoint up to 256 MiB; the CLI checks the account-specific limit before hashing. Custom accounts can receive a higher limit.

Access belongs to each resource slug, not to the whole account.

Access Publish option Who can open it
Public No access option Anyone with the URL
Password protected --password Anyone who knows the password; no Eidos account required
Account private --visibility private The publisher while signed in to the owning eidos.space account

Publishing the same slug again without an access option preserves its current access mode.

Terminal window
eidos publish tracker.eidos --slug tracker --password

The CLI asks for the password twice without echo. A password must contain 8–128 Unicode characters, use at most 256 UTF-8 bytes, and contain no control characters. It is never added to the URL or command arguments.

For automation, put the password in a CI or shell secret named EIDOS_PUBLISH_PASSWORD, then still pass --password:

Terminal window
# EIDOS_PUBLISH_PASSWORD is supplied by the secret manager.
eidos publish tracker.eidos --slug tracker --password

Running the command again with a new password rotates it. Existing browser sessions stop working immediately. A correct password creates a host-only, HttpOnly browser session for up to 12 hours; repeated failures are temporarily rate-limited.

Remove password protection and make the resource public explicitly:

Terminal window
eidos publish tracker.eidos --slug tracker --remove-password
Terminal window
eidos publish tracker.eidos --slug tracker --visibility private

Account-private access is currently owner-only. Opening the URL redirects to eidos.space sign-in and returns to the resource after the owning account is verified. Use password protection instead when sharing with people who do not have the publisher’s account.

Published Eidos Files, Markdown documents, and Forms show the Built with Eidos badge by default. Publish can hide it for one resource without creating a new content Version:

Terminal window
eidos publish tracker.eidos --slug tracker --hide-branding

Restore the badge with --show-branding. Omitting both options preserves the resource’s current setting. The same control is available beside each resource on the Publish account page and in Eidos Lite’s Publish panel.

A slug identifies one long-lived resource. Publishing another file with a new slug creates another resource under the same canonical hostname:

Terminal window
eidos publish roadmap.eidos --slug roadmap
eidos publish inventory.eidos --slug inventory

Publishing new bytes to an existing slug creates a new immutable Version while keeping its URL stable. Publishing the same bytes and attachment references is a no-op for Version history. Resource count is not a commercial quota; storage and the history policy are. Current standard Publish limits are:

Limit Publish
Deduplicated account storage 10 GiB
One .eidos entrypoint 256 MiB
One source attachment 1 GiB
Markdown document 16 MiB
Inactive Version history 30 days
Resources No quota
Access modes Public, password, account-private
Canonical hostname One independent Publish handle
Remove Built with Eidos Yes
Form responses per month 5,000
Collect Inbox 5 GiB
Attachments per response 20
One submitted attachment 100 MiB
Imported response retention 30 days

Contact Eidos for a Custom plan when an .eidos file needs a higher limit or dedicated Runtime capacity. These limits apply to paid Publish; local build and preview remain free. Paid history retention starts when an active Version is replaced. Inactive Versions are kept for 30 days. Failed or never-activated Versions are removed after 24 hours. The currently active Version is never removed by history retention. Expired history releases only content no remaining Version references. Form definition snapshots needed to interpret collected responses are retained separately from the full published source.

The account page is authoritative for the current plan and usage. External custom domains are not part of Publish 1.0.

Publish Free accepts Markdown up to 2 MiB, at most 20 attachments of 25 MiB each, and a Source Bundle up to 50 MiB. All retained source and generated artifacts share the 100 MiB account quota. Free allows 20 new version uploads per UTC day. Republishing the same slug does not use another slot. Use Unpublish on the account Resources page to release a slot; retained versions continue to count toward storage until cleanup. Free retains the previous version for 24 hours. Public links remain accessible to anyone who knows the URL despite noindex.

Use normal output when publishing interactively so progress remains visible. Use global --json when a script needs one stable result document:

Terminal window
eidos --json publish tracker.eidos --slug tracker

JSON mode writes one result to stdout and errors to stderr. It does not render the interactive progress display. publishFingerprint identifies the complete Source Bundle, while versionCreated tells automation whether this run created a Version or reused the active one.

  • Use Publish for a stable, hosted, read-only snapshot. The local CLI does not need to remain online.
  • Use eidos serve --relay for a live editor backed by the file on your computer. The Serve process must keep running.

A Publish subscription is required

Local preview does not create a hosted URL. Activate Publish from the account or pricing page, then retry with the same file and slug.

The storage limit has been reached

Delete unneeded inactive Versions or reduce database/attachment bytes. Reusing identical content does not consume storage twice. Standard .eidos files are limited to 256 MiB, while source attachments retain the 1 GiB object limit.

An attachment cannot be published

Confirm that it uses a contained relative URI, exists next to the source at that path, and has no symlink path component. For Eidos Files, also confirm the actual size still matches the File entry.

The browser asks for the password again

The password may have been rotated, access may have changed, or the 12-hour session may have expired. Enter the current password again.

eidos publish is not recognized

Update to a CLI build that includes Publish, or build the current repository version.