11 posts tagged with "templates"

Here's the failure we want to save you from. You ship a change, your service restarts, and for the eight seconds it takes your app to boot, every request gets a connection refused or a 502. On a dev Playground nobody notices. On something people actually use during the day, those eight seconds are a pile of errors and a Slack message asking if the site is down.

The fix is one label: fibe.gg/zerodowntime: "true". It flips a service from "stop the old container, start a new one" to a real rolling update — new replicas come up alongside the old ones, and traffic only shifts once the new ones pass a healthcheck. But the label is the easy part. The whole thing lives or dies on whether that healthcheck means anything. A healthcheck that returns 200 the instant the process boots gives you zero downtime and a wall of errors, because you cut traffic over to a replica that isn't actually ready. This guide is about getting both halves right.

You have a Rails app. It has a web service, a Postgres database, and a Sidekiq worker, and it runs on your laptop with a docker-compose.yml you copy-pasted from a blog post two years ago. You want it on Fibe: a real HTTPS URL, live logs, a terminal, source pulled from your repo, secrets that aren't sitting in plaintext, and migrations that run before anyone hits the app.

This post does the whole conversion, top to bottom: we start from a realistic raw Compose file and turn it, one decision at a time, into a polished, launchable template — the kind you'd publish to the Bazaar. By the end you'll have a file you can click Launch on, and a mental model for why each label is there.

You've got a template that works. It launches on your Marquee, the URLs resolve, the database comes up. So you flip the Make public toggle and it's in the Bazaar — instantly, for everyone, with no review queue standing between your YAML and the next person who clicks Launch.

That last part is the whole reason this checklist exists. A public version is live the moment you publish it. There's no reviewer to catch the password you left in a default:, no queue to bounce the template back because you forgot a category. The bar you ship at is the bar you set yourself. This is a walkthrough of how to set it high: what to check, why each check matters to the person on the other end, and a literal copy-paste list at the bottom.

A template that only ever runs one way is just a Compose file with extra ceremony. The whole point of publishing to the Bazaar — or even sharing a template across two Marquees — is that the next person fills in their own subdomain, their own image tag, their own database password, and gets a working environment without editing your YAML. That is what template variables are for.

The catch is that variables in Fibe are not Compose's ${VAR} interpolation. They are a separate compile-time layer with its own declaration block, its own substitution rules, and its own ways to fail. Get the mental model right and they are boring and reliable. Get it wrong and you ship a template that compiles to an empty string in production, or hard-fails on launch with a cryptic error. This guide is the version we wish someone had handed us: how to declare variables, where the values can land, and which mistakes actually bite.

A Fibe Template is a Docker Compose file plus a handful of fibe.gg/* labels. It is meant to be shared — pushed to a Prop, published to the Bazaar, copied by a teammate. Which means the single worst place you can put a database password is the one place it feels most natural to type it: straight into the YAML, next to the service that needs it.

The good news is that you almost never have to. Fibe gives you three distinct homes for sensitive values, and each one exists precisely so that the secret stays out of the Template text. The trick is knowing which home a given value belongs in. This guide walks through all three, the decision that picks between them, and the random / secret / sensitive mechanics that let you author a credential-using Template without ever holding a real credential in your hand.

Every Compose file you bring to Fibe has the same hidden decision baked into it, one service at a time: who gets to reach this thing? On your laptop you answered it by sprinkling ports: entries around until docker compose up let you hit the app in a browser. That habit does not survive contact with a real host. On Fibe, host ports are not how anything becomes reachable, and a ports: line that you think is exposing your app is quietly being stripped before launch.

The good news is that the decision is small and mechanical once you can see it. There are exactly five outcomes for any service — public, internal, root, path-shared, or none — and they're selected by two or three labels in the fibe.gg/* namespace. This guide walks the decision in order, shows the YAML for each pattern, and calls out the gotchas that bite people the first time (the bare-subdomain collision, the at-most-one-@ rule, and why localhost binds are invisible). By the end you'll be able to look at any Compose service and know, in about five seconds, which of the five it is.

Every service in a Fibe template is one of exactly two kinds, and the difference decides everything downstream: whether Fibe clones a repo, whether it runs a build, whether you can edit a file and watch the page reload, and whether a typo in a label hard-fails your launch. The kinds are static (runs a published image) and dynamic (source-backed — Fibe clones, builds, or mounts a Git repo). Most templates are a mix: a dynamic app service in front of a couple of static dependencies.

Here's the part people get wrong: the kind isn't something you declare. There is no fibe.gg/type label. Fibe derives it from the labels you set. Get the signals right and the classifier does the rest; get them subtly wrong and you'll see errors like Service 'web' has a build directive but lacks a fibe.gg/repo_url label. This guide walks the dividing line, then shows you how to wire each kind with real YAML you can copy.

Here is the thing nobody tells you about template errors: most of them are easy once you know who is complaining. Fibe doesn't validate your template in one big pass. It runs a series of layers, each one authoritative for a narrow scope, each one with its own vocabulary. A YAML parser and a launch API say "this is wrong" in completely different dialects. If you can read an error and instantly think "ah, that's the schema layer" or "that's the compiler, not the schema," you stop guessing and start fixing.

This guide walks the layers in order, shows you the exact class of mistake each one catches, and gives you the smallest change that makes it green. The theme throughout: Fibe fails fast and fails specifically, and the earlier a layer catches your problem, the cheaper it is to fix.

A Fibe template is a Docker Compose file with a sprinkling of labels. That's the whole trick. You don't learn a new config language — you annotate the Compose you already know, and the annotations all live under one namespace: fibe.gg/*. Set fibe.gg/port: 3000 on a service and it gets a public HTTPS URL. Set fibe.gg/production: "false" and Fibe mounts your repo into the container so edits show up live. Twenty labels, four jobs.

The catch is that the namespace is strict. An unknown fibe.gg/* key isn't ignored — it's a hard parse error that names the offending service. That's deliberate (a typo'd fibe.gg/prot should fail loudly, not silently route nothing), but it means you want the exact spellings, the exact value rules, and the handful of "label X requires label Y" rules in front of you. This post is that lookup table, grouped the way you actually reach for them.

Every Fibe environment starts as a description before it is ever a running thing. Long before a container exists on a Marquee, before Traefik knows a subdomain, before the wallet is even checked — there is a document that says what this environment is. That document is a Template, and the way Fibe treats it tells you a lot about the platform's whole personality: declarative, versioned, shareable, and unforgiving about typos.

This post is about the authoring layer — what you touch when you decide what an environment should be, not how it gets healed at 3am. We'll walk from a Template to a Playspec to the Bazaar, with stops at variables, the fibe.gg/* config keys, and why unknown keys and unresolved ${...} placeholders hard-fail.