Flatpak Builder Manifest

flatpak-builder manifest files

**/*.flatpak.json**/*.flatpak.yaml**/*.flatpak.yml

Validate

Check your file against this schema

Opens the validator with this schema already loaded. Paste your **/*.flatpak.json and it validates in your browser — nothing is uploaded.

Validate a **/*.flatpak.json → View raw schema

Reference

Fields

Generated directly from the schema, following local $refs, to two levels of nesting.

Field	Type	Description
`app-id`	`string`	A string defining the application id
`id`	`string`	A string defining the application id
`branch`	`string`	The branch to use when exporting the application. If this is unset the defaults come from the default-branch option
`default-branch`	`string`	The default branch to use when exporting the application. Defaults to master. This key can be overridden by the --default-branch commandline option
`collection-id`	`string`	The collection ID of the repository, defaults to being unset. Setting a globally unique collection ID allows the apps in the repository to be shared over peer to peer systems without needing further configuration. If building in an
`extension-tag`	`string`	If building an extension, the tag for the extension point to use. Since flatpak 0.11.4 a runtime may define multiple locations for the same extension point with the intention that different branches for the extension are mounted at each
`runtime`required	`string`	The name of the runtime that the application uses
`runtime-version`	`string`	The version of the runtime that the application uses, defaults to master
`sdk`required	`string`	The name of the development runtime that the application builds with
`var`	`string`	Initialize the (otherwise empty) writable /var in the build with a copy of this runtime
`metadata`	`string`	Use this file as the base metadata file when finishing
`command`	`string`	The filename or path to the main binary of the application. Note that this is really just a single file, not a commandline. If you want to pass arguments, install a shell script wrapper and use that as the command. Also note that the
`build-runtime`	`boolean`	Build a new runtime instead of an application
`build-extension`	`boolean`	Build an extension
`separate-locales`	`boolean`	Separate out locale files and translations to an extension runtime. Defaults to true
`id-platform`	`string`	When building a runtime sdk, also create a platform based on it with this id
`metadata-platform`	`string`	The metadata file to use for the platform we create
`writable-sdk`	`boolean`	If true, use a writable copy of the sdk for /usr. Defaults to true if build-runtime is specified
`appstream-compose`	`boolean`	Run appstream-compose during cleanup phase. Defaults to true
`sdk-extensions`	`array<string>`	Install these extra sdk extensions in /usr
`platform-extensions`	`array<string>`	Install these extra sdk extensions when creating the platform
`base`	`string`	Start with the files from the specified application. This can be used to create applications that extend another application
`base-version`	`string`	Use this specific version of the application specified in base. If unspecified, this uses the value specified in branch
`base-extensions`	`array<string>`	Install these extra extensions from the base application when initializing the application directory
`inherit-extensions`	`array<string>`	Inherit these extra extension points from the base application or sdk when finishing the build
`inherit-sdk-extensions`	`array<string>`	Inherit these extra extension points from the base application or sdk when finishing the build, but do not inherit them into the platform
`tags`	`array<string>`	Add these tags to the metadata file
`build-options`	`object`	Object specifying the build environment
`build-options.cflags`	`string`	This is set in the environment variable CFLAGS during the build. Multiple specifications of this (in e.g. per-arch area) are concatenated, separated by spaces
`build-options.cflags-override`	`boolean`	If this is true, clear cflags from previous build options before adding it from these options
`build-options.cppflags`	`string`	This is set in the environment variable CPPFLAGS during the build. Multiple specifications of this (in e.g. per-arch area) are concatenated, separated by spaces
`build-options.cppflags-override`	`boolean`	If this is true, clear cppflags from previous build options before adding it from these options
`build-options.cxxflags`	`string`	This is set in the environment variable CXXFLAGS during the build. Multiple specifications of this (in e.g. per-arch area) are concatenated, separated by spaces
`build-options.cxxflags-override`	`boolean`	If this is true, clear cxxflags from previous build options before adding it from these options
`build-options.ldflags`	`string`	This is set in the environment variable LDFLAGS during the build. Multiple specifications of this (in e.g. per-arch area) are concatenated, separated by spaces
`build-options.ldflags-override`	`boolean`	If this is true, clear ldflags from previous build options before adding it from these options
`build-options.prefix`	`string`	The build prefix for the modules (defaults to /app for applications and /usr for runtimes)
`build-options.libdir`	`string`	The build libdir for the modules (defaults to /app/lib for applications and /usr/lib for runtimes)
`build-options.append-path`	`string`	This will get appended to PATH in the build environment (with an leading colon if needed)
`build-options.prepend-path`	`string`	This will get prepended to PATH in the build environment (with an trailing colon if needed)
`build-options.append-ld-library-path`	`string`	This will get appended to LD_LIBRARY_PATH in the build environment (with an leading colon if needed)
`build-options.prepend-ld-library-path`	`string`	This will get prepended to LD_LIBRARY_PATH in the build environment (with an trailing colon if needed)
`build-options.append-pkg-config-path`	`string`	This will get appended to PKG_CONFIG_PATH in the build environment (with an leading colon if needed)
`build-options.prepend-pkg-config-path`	`string`	This will get prepended to PKG_CONFIG_PATH in the build environment (with an trailing colon if needed)
`build-options.env`	`object`	This is a dictionary defining environment variables to be set during the build. Elements in this override the properties that set the environment, like cflags and ldflags. Keys with a null value unset the corresponding variable
`build-options.secret-env`	`array<string>`	This is a array defining which host environment variables is transferred to build-commands or post-install environment
`build-options.build-args`	`array<string>`	This is an array containing extra options to pass to flatpak build
`build-options.test-args`	`array<string>`	Similar to build-args but affects the tests, not the normal build
`build-options.config-opts`	`array<string>`	This is an array containing extra options to pass to configure
`build-options.secret-opts`	`array<string>`	This is an array of options that will be passed to configure, meant to be used to pass secrets through host environment variables. Put the option with an environment variables and will be resolved beforehand. '-DSECRET_ID=$CI_SECRET'
`build-options.make-args`	`array<string>`	An array of extra arguments that will be passed to make
`build-options.make-install-args`	`array<string>`	An array of extra arguments that will be passed to make install
`build-options.strip`	`boolean`	If this is true (the default is false) then all ELF files will be stripped after install
`build-options.no-debuginfo`	`boolean`	By default (if strip is not true) flatpak-builder extracts all debug info in ELF files to a separate files and puts this in an extension. If you want to disable this, set no-debuginfo to true
`build-options.no-debuginfo-compression`	`boolean`	By default when extracting debuginfo we compress the debug sections. If you want to disable this, set no-debuginfo-compression to true
`build-options.arch`	`object`	This is a dictionary defining for each arch a separate build options object that override the main one
`modules`	`array`	An array of objects specifying the modules to be built in order. String members in the array are interpreted as the name of a separate json or yaml file that contains a module
`add-extensions`	`object`	This is a dictionary of extension objects. The key is the name of the extension
`add-build-extensions`	`object`	This is a dictionary of extension objects similar to add-extensions. The main difference is that the extensions are added early and are available for use during the build
`cleanup`	`array<string>`	An array of file patterns that should be removed at the end. Patterns starting with / are taken to be full pathnames (without the /app prefix), otherwise they just match the basename
`cleanup-commands`	`array<string>`	An array of commandlines that are run during the cleanup phase
`cleanup-platform`	`array<string>`	Extra files to clean up in the platform
`cleanup-platform-commands`	`array<string>`	An array of commandlines that are run during the cleanup phase of the platform
`prepare-platform-commands`	`array<string>`	An array of commandlines that are run after importing the base platform, but before applying the new files from the sdk. This is a good place to e.g. delete things from the base that may conflict with the files added in the sdk
`finish-args`	`array<string>`	An array of arguments passed to the flatpak build-finish command
`rename-desktop-file`	`string`	Any desktop file with this name will be renamed to a name based on id during the cleanup phase
`rename-appdata-file`	`string`	Any appdata (metainfo) file with this name will be renamed to a name based on id during the cleanup phase
`rename-mime-file`	`string`	Any mimetypes file with this name will me renamed to a name based on id during the cleanup phase
`rename-icon`	`string`	Any icon with this name will be renamed to a name based on id during the cleanup phase. Note that this is the icon name, not the full filenames, so it should not include a filename extension
`rename-mime-icons`	`array<string>`	Any mime icons with any of these names will be renamed to a name prefixed with id during the cleanup phase. Note that this is the icon name, not the full filenames, so it should not include a filename extension
`appdata-license`	`string`	Replace the appdata (metainfo) project_license field with this string. This is useful as the upstream license is typically only about the application itself, whereas the bundled app can contain other licenses too
`copy-icon`	`boolean`	If rename-icon is set, keep a copy of the old icon file
`desktop-file-name-prefix`	`string`	This string will be prefixed to the Name key in the main application desktop file
`desktop-file-name-suffix`	`string`	This string will be suffixed to the Name key in the main application desktop file

Audit

What we found in this schema

Declared draft: draft-07
Validates cleanly against its own meta-schema.
241 properties, 73% carrying a description, max nesting depth 8.

Standards

Specification sections for the keywords in this schema

Keyword	Document	Section
`$ref`	JSON Schema Core, draft 2020-12	§8.2.3.1 — Direct References with "$ref"
`additionalProperties`	JSON Schema Core, draft 2020-12	§10.3.2.3 — "additionalProperties"
`anyOf`	JSON Schema Core, draft 2020-12	§10.2.1.2 — "anyOf"
`const`	JSON Schema Validation, draft 2020-12	§6.1.3 — "const"
`description`	JSON Schema Validation, draft 2020-12	§9.1 — "title" and "description"
`else`	JSON Schema Core, draft 2020-12	§10.2.2.3 — "else"
`enum`	JSON Schema Validation, draft 2020-12	§6.1.2 — "enum"
`if`	JSON Schema Core, draft 2020-12	§10.2.2.1 — "if"
`items`	JSON Schema Core, draft 2020-12	§10.3.1.2 — "items"
`oneOf`	JSON Schema Core, draft 2020-12	§10.2.1.3 — "oneOf"
`pattern`	JSON Schema Validation, draft 2020-12	§6.3.3 — "pattern"
`patternProperties`	JSON Schema Core, draft 2020-12	§10.3.2.2 — "patternProperties"
`properties`	JSON Schema Core, draft 2020-12	§10.3.2.1 — "properties"
`required`	JSON Schema Validation, draft 2020-12	§6.5.3 — "required"
`then`	JSON Schema Core, draft 2020-12	§10.2.2.2 — "then"
`type`	JSON Schema Validation, draft 2020-12	§6.1.1 — "type"

Documents

JSON Schema Core, draft 2020-12 — JSON Schema: A Media Type for Describing JSON Documents, A. Wright, H. Andrews, B. Hutton, G. Dennis, Eds., 2022. draft-bhutton-json-schema-01. An expired Internet-Draft with no formal standing in the IETF standards process; it is nonetheless the specification of record for JSON Schema 2020-12, published by json-schema.org.
JSON Schema Validation, draft 2020-12 — JSON Schema Validation: A Vocabulary for Structural Validation of JSON, A. Wright, H. Andrews, B. Hutton, Eds., 2022.
RFC 8259 (STD 90) — The JavaScript Object Notation (JSON) Data Interchange Format, T. Bray, Ed., 2017. The format a schema describes.
RFC 6901 — JavaScript Object Notation (JSON) Pointer. Defines the pointer syntax used by $ref fragments and the ~0 / ~1 escapes.

Source

Attribution

This schema comes from SchemaStore, distributed under the Apache License 2.0. Copyright 2015–present Mads Kristensen and contributors. View the original file. The field table and audit on this page are generated by JSONTools.tools; the schema itself is unmodified.

← All schemas