Getting started
Installing Fyra
Fyra is a command-line tool. Install it once, globally, and you're set up
for every project on your machine.
1
Install the CLI
Fyra is a single self-contained binary — no runtimes to install. Paste this into your terminal on macOS or Linux:
Terminal
$
curl -fsSL https://fyra.sh/install.sh | sh
This places the fyra binary in /usr/local/bin. You can now use it from any directory.
2
Create an account
Register with your email address. You'll use these credentials every time you log in on a new machine.
Terminal
$
fyra register
Email: you@example.com
Password: ········
Confirm password: ········
Account created. Check your email to verify your address.
3
Log in
Once your email is verified, log in. Your session token is saved to ~/.fyra/config.yaml so you stay logged in across terminal sessions.
Terminal
$
fyra login
Email: you@example.com
Password: ········
Logged in successfully.
Already have an account? Skip registration and go straight to fyra login.
Getting started
Your first deploy
Once you're logged in, deploying a site is two commands: one to create the
app, one to push it. After that, a single fyra push is all you need.
1
Go to your project directory
Navigate to the folder you want to deploy. It can be a plain HTML folder, the output of a build tool, or anything static.
2
Create the app
This registers your app and writes a .deploy.yaml file in the current directory. Pass --appname to choose your own slug, or leave it out for a random one like quiet-river.
Terminal
$
fyra create --appname my-site
Created app: my-site
Run 'fyra push' to deploy this directory.
3
Push it live
Fyra tarballs your directory in memory and streams it to the server over gRPC. The CDN is updated automatically once the deploy completes.
Terminal
$
fyra push
Scanning my-site...
Packing 24 files (840.0 KB)
Uploading... 840.0 KB sent
Deploying on server...
Done: https://my-site.apps.fyra.sh
Next time, just run fyra push from the same directory — no flags needed. The .deploy.yaml remembers which app to update.
Domains
Custom domains
Point any domain you own at your Fyra app. The process is three steps:
register the domain with Fyra, add a CNAME at your DNS provider, then
run a check to confirm everything is wired up correctly.
1
Register the domain
From your project directory, run fyra set-domain with the domain you want to use. Fyra prints the exact CNAME target you'll need in the next step.
Terminal
$
fyra set-domain shop.example.com
Custom domain set to shop.example.com.
Point your CNAME for shop.example.com → shop-example-com.ignite.fyra.sh
Run 'fyra check-domains' to verify once DNS propagates.
2
Add the CNAME record
Log in to your DNS provider and create a CNAME record pointing your domain at the target Fyra gave you. The target is always your domain with dots replaced by dashes, followed by .ignite.fyra.sh.
DNS record (example)
Type Host Value
CNAME shop.example.com shop-example-com.ignite.fyra.sh
Apex domains (example.com without a subdomain) work too. If your DNS provider is Cloudflare, enable Proxied mode — Cloudflare flattens the CNAME into A records automatically and Fyra handles this correctly.
3
Verify and activate
Once DNS has propagated (usually a few minutes), run fyra check-domains. It confirms the CNAME is live, waits for your TLS certificate to be issued, and then verifies the site is reachable over HTTPS.
Terminal
$
fyra check-domains
Have you added a CNAME for shop.example.com → shop-example-com.ignite.fyra.sh? [y/N] y
✓ CNAME verified.
Certificate status: provisioning…
✓ Custom domain is live at https://shop.example.com
DNS not propagated yet? The check will tell you. Wait a minute and run it again — propagation rarely takes more than 5 minutes for most providers.
Removing a custom domain? Run fyra remove-domain from the project directory. Your site reverts to its slug.apps.fyra.sh address immediately.
Domains
SSL & HTTPS
Every Fyra site — both on apps.fyra.sh subdomains and custom
domains — is served exclusively over HTTPS. There is nothing to
configure: certificates are issued and renewed automatically.
1
Your *.apps.fyra.sh subdomain
When you push your first deploy, your app is immediately available at https://your-app.apps.fyra.sh. The wildcard TLS certificate covering *.apps.fyra.sh is managed by Fyra — there is nothing to activate.
2
Custom domain certificates
When you point a custom domain at Fyra, the server provisions a dedicated TLS certificate via Let's Encrypt as soon as it sees your CNAME in DNS. The fyra check-domains command waits for this to complete — usually under two minutes — before confirming your site is live.
Certificate lifecycle
CNAME verified → cert requested → cert issued → HTTPS live
3
Automatic renewal
Certificates renew automatically before they expire. You will never need to manually renew, upload, or rotate a certificate. HTTP traffic is redirected to HTTPS by default — there is no option to serve over plain HTTP.
Certificate not issued? The most common cause is a missing or incorrect CNAME. Run fyra check-domains — it will tell you exactly what to fix before attempting to issue the cert.
Customization
Custom 404 page
When a visitor hits a URL that doesn't exist on your site, Fyra
serves a default plain-text 404 response. You can replace that with
your own branded page by adding a single file to your project root.
1
Create a 404.html file
Place a file named exactly 404.html in the root of your project directory — the same folder you run fyra push from. This file can contain any valid HTML.
Project structure
my-site/
├── index.html
├── about.html
├── 404.html ← your custom error page
└── styles/
└── main.css
2
Write your page
Design it however you like — use your own CSS, images, and scripts. A good 404 page includes a friendly message, a link back home, and optionally a search field or suggested pages.
404.html — minimal example
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<title>Page not found</title>
</head>
<body>
<h1>404</h1>
<p>Nothing here — try the <a href="/">home page</a>.</p>
</body>
</html>
3
Deploy it
Push your site as usual. Fyra detects the 404.html in your tarball and configures the web server to serve it for any request that doesn't match a file.
Terminal
$
fyra push
Scanning my-site...
Packing 25 files (842.3 KB)
Custom 404 page detected — will be served for not-found URLs.
Uploading... 842.3 KB sent
Done: https://my-site.apps.fyra.sh
No 404.html file? Fyra serves a plain 404 Not Found text response by default. Adding the file is entirely optional — your site works without it.
Customization
Excluding files from upload
By default, fyra push uploads everything in your project
directory — except .git, node_modules, and
.deploy.yaml, which are always skipped. Add a
.fyraignore file to exclude anything else: build
caches, private config files, source assets, or local tooling.
1
Create a .fyraignore file
Place a file named .fyraignore in the root of your project directory — the same folder you run fyra push from. It uses the same syntax as .gitignore: one pattern per line, with # for comments and ! to negate a rule.
.fyraignore — example
# Dependencies and build output
node_modules/
.cache/
# Private config
.env
.env.local
# Source files not needed at runtime
src/
*.sketch
*.psd
2
Verify what will be uploaded
Run fyra push normally — it prints the file count and total size before uploading. If the numbers look smaller than expected, your ignore rules are working. There is no separate dry-run command.
Terminal
$
fyra push
Scanning my-site...
Packing 18 files (210.4 KB)
Uploading... 210.4 KB sent
Done: https://my-site.apps.fyra.sh
3
What's always excluded
Even without a .fyraignore, Fyra automatically skips a few things on every push:
Always excluded
.git/ version control history
node_modules/ npm / yarn packages
.deploy.yaml fyra app metadata
You do not need to list these in .fyraignore.
Tip: If you already have a .gitignore, your .fyraignore is often a subset of it — copy the relevant lines and leave out anything your server actually needs (like compiled output in dist/).