Overview
The FM Developer Portal is a web application that bridges FileMaker Server backups and the FileMaker Server hosting environment. It connects to FileMaker Servers via SSH and the FileMaker Admin API, and lets you perform server operations from a browser — without needing SSH access or command-line tools.
It also publishes the monthly OS-patching schedule for the servers you can reach, and lets you change it — see Maintenance below. That part covers non-FileMaker web application servers too, since the patching automation behind it is the same either way.
After logging in, the homepage presents the available operations as selectable cards, each marked with an Experimental badge. Click an operation to begin.
Available operations
| Operation | Primary use | What it does |
|---|---|---|
| Host from Backup — On-Server | Ad-hoc, recent backups | Browse the backups kept on a server’s own disk over SSH and copy a .fmp12 file into the hosted databases folder, optionally across servers. Fastest option. |
| Host from Backup — Object Storage | Restore an older backup | Uses AWX to restore a .fmp12 from a server’s off-site object-storage (duplicity) backups and host it in FileMaker. Reaches further back than on-disk backups, but slower. Defaults to a timestamped name; overwriting an existing file is allowed with the same safeguards as the on-server flow (close, back up first, confirm). |
| Data Migration | Promote dev to prod | Uses AWX to run the FMDataMigration tool — copies schema from a source (dev) file into a target (prod) file, preserving the target’s live data. |
| Data Refresh | Refresh dev with prod data | Uses AWX to run the FMDataMigration tool in reverse — copies production data into a development file’s schema structure. Never targets a production server. |
| Live File Transfer | Copy a hosted file between servers | Copies a currently hosted .fmp12 file directly to a server in its deploy chain over SSH — pausing or snapshotting the live file safely, then opening it on the target. |
| Live File Copy | Duplicate a hosted file on its own server | Pauses a currently hosted .fmp12 file just long enough to duplicate it on the same server under a new name. Copies never overwrite an existing file. |
| Download File | Get a file onto your machine | Downloads a backup or live .fmp12 to your computer over SSH; live files are snapshotted (paused briefly) for a consistent copy, with optional gzip compression. |
| File Corruption Check | Detect file corruption | Uses AWX to recover a backup with FMDeveloperTool and export XML of the original and recovered copies. Diffing them reveals what recovery changed — the signal that a file is corrupt. |
| File Compact | Reclaim disk space | Uses AWX to rewrite a backup or live .fmp12 without its free and fragmented blocks (FMDeveloperTool --copyCompress). The copy can be left in staging, hosted under a new name, or swapped in for the original — the last being the only one that actually reclaims the space. A live source is closed while it is compacted. |
| File Encryption | Turn encryption at rest on or off | Runs FMDeveloperTool --enableEncryption / --removeEncryption over SSH (not AWX) to encrypt a backup or live .fmp12, decrypt one, or change its passcode. The result can be left in staging, hosted under a new name, or swapped in for the original. A live source is closed while the tool runs. The passcode is supplied by the operator and never stored by the portal. |
Maintenance
Three features cover the monthly OS-patching automation rather than FileMaker files, and they are the ones that also apply to non-FileMaker web application servers:
| Feature | Primary use | What it does |
|---|---|---|
| Maintenance Calendar | See when a server is next going down | A month grid of every patching window on the servers you can reach, including windows that have been skipped, moved or re-timed. Subscribe to it from Calendar on your Mac and it stays current by itself. |
| Maintenance Windows | A month where a reboot lands badly, or one that needs an extra run | Skip that month’s patching and reboot, move it to another date in the same month, or keep the day and change the hour. A window that has already passed can be given a later date in the same month, which adds a run — the way to get a FileMaker upgrade or late OS update out this month. Reminder emails follow the change, and patching resumes on its own. |
| Maintenance Contacts | Who hears about a window | Set the two recipient lists behind the patching notices — the customer’s and the project team’s — per client team, or per host where one needs to differ. Changes apply to the next notice. |
If your team’s servers are web applications rather than FileMaker, these are what the portal offers you and the FileMaker operations above are hidden.
Disk-capacity policy
Every operation that writes to a server projects what it will do to the volume it writes to — the incoming file, plus any copy it makes of the file being replaced — and applies the same three tiers to the projected usage:
| Projected usage after the run | What happens |
|---|---|
| Up to 90% | The run proceeds normally. |
| 90% – 95% | The launch button stays disabled until you tick I understand this will take the disk above 90%. The checkbox sits under the disk card on the review step. |
| Above 95% | Refused. Free up space first. Superusers can override it, but only by ticking both the 90% acknowledgement and a separate override checkbox. |
Two things sit outside the tiers:
- A file that will not fit at all is always refused. No acknowledgement, and no superuser override, creates free blocks.
- When the projection can’t be worked out — the server is unreachable, or the size of the incoming file can’t be measured in advance (a re-host from object storage cannot know the restored size until it has restored it) — the acknowledgement is required. An unknown projection is never a silent pass, and never a dead end either.
The decision is always made against a disk reading taken at launch, not against what the review page showed you, so a page left open while the disk filled up is re-judged rather than trusted. Two settings adjust the thresholds portal-wide: DISK_ACK_THRESHOLD_PCT (default 90) and DISK_HARD_LIMIT_PCT (default 95).
Reading the disk figures
Every disk card states usage at three points, as a percentage with the free space beneath it:
| Figure | Meaning |
|---|---|
| Used now | What the volume holds before anything is written. |
| Peak during | The most it holds at once while the run is in progress. This is the figure the tiers above are applied to. |
| After | What stays in use once the run has finished. |
Peak and After usually match, because a file written to a server stays there. They differ when the run gives space back — a live download stages a snapshot, sends it and deletes it, so the volume ends where it started even though it has to hold both for a while. Where that happens the card says so explicitly.
The percentages are the used percentage, matching both the 90%/95% thresholds and what df reports on the host, so the number on screen is the number an operator sees on the server. On a filesystem with reserved blocks a bar segment can read a point or two below the percentage beside it, because the segments are drawn as fractions of the total while the percentage uses df’s own denominator.
The tiers are judged on Peak, not After: a run that would overrun the volume halfway through overruns it regardless of what it tidies up afterwards.
On the streaming flows — Live File Transfer, Live File Copy — the progress page shows the same three figures and fills them in as it goes: Before and After are measured, and During starts as the projection and is replaced by real readings taken while the copy runs, where the flow has a copy loop to sample. The label says which of the two it currently is.
Templates
Recurring Data Migration and Data Refresh operations can be saved as templates from the wizard’s review step. The Templates section in the navbar lists every template you can see (shared with everyone who has access to both of its servers) and gives each one a three-part flow: Overview of its parameters, Verify pre-flight checks against the live servers, and Run.
Access
These guides are served by the portal — go to the portal.
Contact the DevOps team to have an account provisioned. Once your account exists, set your password by clicking Forgot your password? / First Login? on the login page — use the work email address the account was created against when prompted.
Terminology
| Term | Meaning |
|---|---|
| Server | A server configured in the portal. You only see servers you have been granted access to. Most are FileMaker Servers; some are web application servers, which appear only in the Maintenance Calendar, Maintenance Windows and Maintenance Contacts. |
| Backup file | A .fmp12 file found in a server’s backup directory. |
| Databases folder | The folder FileMaker Server monitors for files to host. Copying a file here makes it available for FileMaker Server to open. |
| Deploy chain | A pre-configured relationship between servers (e.g. Development → Production). Enables cross-server operations in one step. |
| EAR key | Encryption at Rest key — required when opening an encrypted FileMaker database. Also called the passcode by FMDeveloperTool (-passcode sets it; -encryption_key supplies the one a file already has). Stored per host in 1Password as fms-ear-key_<host>. |
| Shared ID | FMDeveloperTool -sharedID. An identifier encrypted files share so that files with the same EAR key open each other without prompting. |
| Container data | External container storage directories associated with a database. Can be synced alongside the .fmp12 file during cross-server operations. |
| Clone host | Migration only: the server providing the clone (schema) file, typically development. It is not where the live data lives. |
| Data host | The server holding the live/production data. In a migration it holds the data file that is overwritten with the migrated result; in a refresh it provides the data that is copied. |
| Refresh host | Refresh only: the development server whose file is refreshed (schema kept, data replaced). Never a production server. |
| Source / target host | Used only by the live file transfer flow (a straight file copy) and in AWX variable names, where they describe transfer direction. |
| Schema file | The .fmp12 file whose structure (schema) is used as the template in a DMT operation. |
| Data file | The .fmp12 file whose records are migrated into the schema template. |
| AWX | The Ansible automation platform that executes data migration, refresh, corruption-check, and object-storage re-host jobs, and that runs the monthly OS patching. The portal submits jobs to AWX and polls for results, and owns the schedules behind the Maintenance Calendar. |
| Maintenance window | The recurring monthly slot in which a server is patched and rebooted, roughly an hour long. Defined in AWX and always quoted in Pacific time. |
| Maintenance contacts | The two lists of people emailed about a server’s maintenance window — the customer (addressed on the To line) and the project team (on Cc unless there are no customer contacts). Held per client team, and per host where one needs to differ. Our IT team is added to every notice regardless. |
| Template | A saved, reusable option set for a workflow (currently migration and refresh), created from the wizard’s review step and managed in the Templates section. Visible to everyone with access to both of its servers. |
| File recovery | Running FMDeveloperTool --recover on a backup to produce a repaired copy. The corruption check compares the recovered copy against the original to detect damage. |
What the portal does not do
- It does not create backups — it only reads existing ones.
- It does not modify database content directly.
- It does not replace FileMaker Server’s own backup schedule.
History page
Every operation is recorded with the files involved, the user who performed it, and whether it succeeded. The History page is one feed of every operation, newest first, with running jobs pinned above it and a filter bar for result, time range, server, user, and file name. Tabs narrow the feed to a single operation type: Host from Backup — On-Server, Host from Backup — Object Storage, Data migrations, Data refreshes, Live file transfers, Live file copies, File downloads, and File corruption checks. The AWX-driven operations also link to their job output.
Result badges: OK (green), Failed (red, tooltip shows error), Canceled (yellow).
Staff users can filter the history by user.