GitHub Dockerfile Monthly Trending

oxsecurity/megalinter

🦙 MegaLinter analyzes 50 languages, 22 formats, 21 tooling formats, excessive copy-pastes, spelling mistakes and security issues in your repository sources with a GitHub Action, other CI tools or locally.

MegaLinter, by

MegaLinter is an open-source tool for CI/CD workflows that analyzes the consistency of your code, IaC, configuration, and scripts in your repository to ensure all your project sources are clean and formatted, no matter which IDE or toolbox is used by your developers. Powered by OX Security.

Supports 69 languages, 23 formats, 21 tooling formats, and is ready to use out of the box as a GitHub Action or with any CI system. It is highly configurable and free for all uses.

MegaLinter has native integrations with many major CI/CD tools.

Upgrade to MegaLinter v9 :):

Use the new LLM Advisor that will tell you how to fix linters issues
Create your own MegaLinter Custom Flavors to improve performance

Before you go further, see the online documentation website, which offers much easier navigation than this README

Why MegaLinter

Projects need to contain clean code in order to avoid technical debt, which makes ongoing maintenance harder and more time-consuming.

By using code formatters and code linters, you ensure that your codebase is easier to read and follows best practices, from kickoff through each step of the project lifecycle.

Not all developers use linters in their IDEs, which makes code reviews harder and longer to process.

By using MegaLinter, you'll enjoy the following benefits for your team:

At each pull request, it automatically analyzes all updated code across all languages.
By reading error logs, developers learn best practices for the languages they use.
The MegaLinter documentation provides a list of IDE plugins for each linter, so developers know which linter and plugins to install.
MegaLinter works out of the box after a quick setup.
Formatting and fixes can be automatically applied directly to the Git branch or provided in reports.
This tool is 100% open source and free for all uses (personal, professional, public, and private repositories).
MegaLinter can run on any CI tool and be run locally: no need to authorize an external application, and your codebase never leaves your tooling ecosystem.

Quick Start

Run npx mega-linter-runner --install to generate configuration files (you need Node.js installed).
Commit, push, and create a pull request.
Watch!

Notes:

This repo is a hard fork of GitHub Super-Linter, rewritten in Python to add many additional features.
If you are a Super-Linter user, you can transparently switch to MegaLinter and keep the same configuration (just replace super-linter/super-linter@v3 with oxsecurity/megalinter@v9 in your GitHub Action YAML file, like on this PR).
If you want to use MegaLinter's extra features (recommended), please take 5 minutes to use the assisted installation.
For a beginner-friendly example of getting started with MegaLinter, check out this blog post by Alec Johnson.

Supported Linters

All linters are integrated into the MegaLinter Docker image, which is frequently updated with their latest versions.

Languages

	Language	Linter	Additional
	BASH	bash-exec BASH_EXEC
	BASH	shellcheck BASH_SHELLCHECK
	BASH	shfmt BASH_SHFMT
	C	cppcheck C_CPPCHECK
	C	cpplint C_CPPLINT
	C	clang-format C_CLANG_FORMAT
	CLOJURE	clj-kondo CLOJURE_CLJ_KONDO
	CLOJURE	cljstyle CLOJURE_CLJSTYLE
	COFFEE	coffeelint COFFEE_COFFEELINT
	C++ (CPP)	cppcheck CPP_CPPCHECK
	C++ (CPP)	cpplint CPP_CPPLINT
	C++ (CPP)	clang-format CPP_CLANG_FORMAT
	C# (CSHARP)	dotnet-format CSHARP_DOTNET_FORMAT
	C# (CSHARP)	csharpier CSHARP_CSHARPIER
	C# (CSHARP)	roslynator CSHARP_ROSLYNATOR
	DART	dartanalyzer DART_DARTANALYZER
	GO	golangci-lint GO_GOLANGCI_LINT
	GO	revive GO_REVIVE
	GROOVY	npm-groovy-lint GROOVY_NPM_GROOVY_LINT
	JAVA	checkstyle JAVA_CHECKSTYLE
	JAVA	pmd JAVA_PMD
	JAVASCRIPT	eslint JAVASCRIPT_ES
	JAVASCRIPT	standard JAVASCRIPT_STANDARD
	JAVASCRIPT	prettier JAVASCRIPT_PRETTIER
	JSX	eslint JSX_ESLINT
	KOTLIN	ktlint KOTLIN_KTLINT
	KOTLIN	detekt KOTLIN_DETEKT
	LUA	luacheck LUA_LUACHECK
	LUA	selene LUA_SELENE
	LUA	stylua LUA_STYLUA
	MAKEFILE	checkmake MAKEFILE_CHECKMAKE
	PERL	perlcritic PERL_PERLCRITIC
	PHP	phpcs PHP_PHPCS
	PHP	phpstan PHP_PHPSTAN
	PHP	psalm PHP_PSALM
	PHP	phplint PHP_PHPLINT
	PHP	php-cs-fixer PHP_PHPCSFIXER
	POWERSHELL	powershell POWERSHELL_POWERSHELL
	POWERSHELL	powershell_formatter POWERSHELL_POWERSHELL_FORMATTER
	PYTHON	pylint PYTHON_PYLINT
	PYTHON	black PYTHON_BLACK
	PYTHON	flake8 PYTHON_FLAKE8
	PYTHON	isort PYTHON_ISORT
	PYTHON	bandit PYTHON_BANDIT
	PYTHON	mypy PYTHON_MYPY
	PYTHON	nbqa PYTHON_NBQA_MYPY
	PYTHON	pyright PYTHON_PYRIGHT
	PYTHON	ruff PYTHON_RUFF
	PYTHON	ruff-format PYTHON_RUFF_FORMAT
	R	lintr R_LINTR
	RAKU	raku RAKU_RAKU
	RUBY	rubocop RUBY_RUBOCOP
	RUST	clippy RUST_CLIPPY
	SALESFORCE	code-analyzer-apex SALESFORCE_CODE_ANALYZER_APEX
	SALESFORCE	code-analyzer-aura SALESFORCE_CODE_ANALYZER_AURA
	SALESFORCE	code-analyzer-lwc SALESFORCE_CODE_ANALYZER_LWC
	SALESFORCE	sfdx-scanner-apex SALESFORCE_SFDX_SCANNER_APEX
	SALESFORCE	sfdx-scanner-aura SALESFORCE_SFDX_SCANNER_AURA
	SALESFORCE	sfdx-scanner-lwc SALESFORCE_SFDX_SCANNER_LWC
	SALESFORCE	lightning-flow-scanner SALESFORCE_LIGHTNING_FLOW_SCANNER
	SCALA	scalafix SCALA_SCALAFIX
	SQL	sqlfluff SQL_SQLFLUFF
	SQL	tsqllint SQL_TSQLLINT
	SWIFT	swiftlint SWIFT_SWIFTLINT
	TSX	eslint TSX_ESLINT
	TYPESCRIPT	eslint TYPESCRIPT_ES
	TYPESCRIPT	ts-standard TYPESCRIPT_STANDARD
	TYPESCRIPT	prettier TYPESCRIPT_PRETTIER
	Visual Basic .NET (VBDOTNET)	dotnet-format VBDOTNET_DOTNET_FORMAT

Formats

	Format	Linter	Additional
	CSS	stylelint CSS_STYLELINT
	ENV	dotenv-linter ENV_DOTENV_LINTER
	GRAPHQL	graphql-schema-linter GRAPHQL_GRAPHQL_SCHEMA_LINTER
	HTML	djlint HTML_DJLINT
	HTML	htmlhint HTML_HTMLHINT
	JSON	jsonlint JSON_JSONLINT
	JSON	eslint-plugin-jsonc JSON_ESLINT_PLUGIN_JSONC
	JSON	v8r JSON_V8R
	JSON	prettier JSON_PRETTIER
	JSON	npm-package-json-lint JSON_NPM_PACKAGE_JSON_LINT
	LATEX	chktex LATEX_CHKTEX
	MARKDOWN	markdownlint MARKDOWN_MARKDOWNLINT
	MARKDOWN	remark-lint MARKDOWN_REMARK_LINT
	MARKDOWN	markdown-table-formatter MARKDOWN_MARKDOWN_TABLE_FORMATTER
	MARKDOWN	rumdl MARKDOWN_RUMDL
	PROTOBUF	protolint PROTOBUF_PROTOLINT
	RST	rst-lint RST_RST_LINT
	RST	rstcheck RST_RSTCHECK
	RST	rstfmt RST_RSTFMT
	XML	xmllint XML_XMLLINT
	YAML	prettier YAML_PRETTIER
	YAML	yamllint YAML_YAMLLINT
	YAML	v8r YAML_V8R

Tooling formats

	Tooling format	Linter	Additional
	ACTION	actionlint ACTION_ACTIONLINT
	ANSIBLE	ansible-lint ANSIBLE_ANSIBLE_LINT
	API	spectral API_SPECTRAL
	ARM	arm-ttk ARM_ARM_TTK
	BICEP	bicep_linter BICEP_BICEP_LINTER
	CLOUDFORMATION	cfn-lint CLOUDFORMATION_CFN_LINT
	DOCKERFILE	hadolint DOCKERFILE_HADOLINT
	EDITORCONFIG	editorconfig-checker EDITORCONFIG_EDITORCONFIG_CHECKER
	GHERKIN	gherkin-lint GHERKIN_GHERKIN_LINT
	KUBERNETES	kubeconform KUBERNETES_KUBECONFORM
	KUBERNETES	helm KUBERNETES_HELM
	KUBERNETES	kubescape KUBERNETES_KUBESCAPE
	PUPPET	puppet-lint PUPPET_PUPPET_LINT
	ROBOTFRAMEWORK	robocop ROBOTFRAMEWORK_ROBOCOP
	SNAKEMAKE	snakemake SNAKEMAKE_LINT
	SNAKEMAKE	snakefmt SNAKEMAKE_SNAKEFMT
	TEKTON	tekton-lint TEKTON_TEKTON_LINT
	TERRAFORM	tflint TERRAFORM_TFLINT
	TERRAFORM	terrascan TERRAFORM_TERRASCAN
	TERRAFORM	terragrunt TERRAFORM_TERRAGRUNT
	TERRAFORM	terraform-fmt TERRAFORM_TERRAFORM_FMT

Other

	Code quality checker	Linter	Additional
	COPYPASTE	jscpd COPYPASTE_JSCPD
	REPOSITORY	checkov REPOSITORY_CHECKOV
	REPOSITORY	devskim REPOSITORY_DEVSKIM
	REPOSITORY	dustilock REPOSITORY_DUSTILOCK
	REPOSITORY	git_diff REPOSITORY_GIT_DIFF
	REPOSITORY	gitleaks REPOSITORY_GITLEAKS
	REPOSITORY	grype REPOSITORY_GRYPE
	REPOSITORY	kics REPOSITORY_KICS
	REPOSITORY	ls-lint REPOSITORY_LS_LINT
	REPOSITORY	secretlint REPOSITORY_SECRETLINT
	REPOSITORY	semgrep REPOSITORY_SEMGREP
	REPOSITORY	syft REPOSITORY_SYFT
	REPOSITORY	trivy REPOSITORY_TRIVY
	REPOSITORY	trivy-sbom REPOSITORY_TRIVY_SBOM
	REPOSITORY	trufflehog REPOSITORY_TRUFFLEHOG
	REPOSITORY	kingfisher REPOSITORY_KINGFISHER
	SPELL	cspell SPELL_CSPELL
	SPELL	proselint SPELL_PROSELINT
	SPELL	vale SPELL_VALE
	SPELL	lychee SPELL_LYCHEE
	SPELL	codespell SPELL_CODESPELL

Installation

Assisted installation

Just run npx mega-linter-runner --install at the root of your repository and answer questions, it will generate ready to use configuration files for MegaLinter :)

Which version to use ?

The following instructions examples are using latest MegaLinter stable version (v9 , always corresponding to the latest release)

Docker image: oxsecurity/megalinter:v9
GitHub Action: oxsecurity/megalinter@v9

You can also use beta version (corresponding to the content of main branch)

Docker image: oxsecurity/megalinter:beta
GitHub Action: oxsecurity/megalinter@beta

GitHub Action

Create a new file in your repository called .github/workflows/mega-linter.yml
Copy the example workflow from below into that new file, no extra configuration required
Commit that file to a new branch
Open up a pull request and observe the action working
Enjoy your more stable, and cleaner code base

NOTES:

If you pass the Environment variable GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} in your workflow, then the MegaLinter will mark the status of each individual linter run in the Checks section of a pull request. Without this you will only see the overall status of the full run. There is no need to set the GitHub Secret as it's automatically set by GitHub, it only needs to be passed to the action.
You can also use it outside of GitHub Actions (CircleCI, Azure Pipelines, Jenkins, GitLab, or even locally with a docker run) , and have status on Github Pull Request if GITHUB_TARGET_URL environment variable exists.

In your repository you should have a .github/workflows folder with GitHub Action similar to below:

.github/workflows/mega-linter.yml

This file should have this code

---
# MegaLinter GitHub Action configuration file
# More info at https://megalinter.io
name: MegaLinter

on:
  # Trigger mega-linter at every push. Action will also be visible from Pull Requests to main
  push: # Comment this line to trigger action only on pull-requests (not recommended if you don't pay for GH Actions)
  pull_request:
    branches: [master, main]

env: # Comment env block if you don't want to apply fixes
  # Apply linter fixes configuration
  APPLY_FIXES: all # When active, APPLY_FIXES must also be defined as environment variable (in github/workflows/mega-linter.yml or other CI tool)
  APPLY_FIXES_EVENT: pull_request # Decide which event triggers application of fixes in a commit or a PR (pull_request, push, all)
  APPLY_FIXES_MODE: commit # If APPLY_FIXES is used, defines if the fixes are directly committed (commit) or posted in a PR (pull_request)

concurrency:
  group: ${{ github.ref }}-${{ github.workflow }}
  cancel-in-progress: true

jobs:
  megalinter:
    name: MegaLinter
    runs-on: ubuntu-latest
    permissions:
      # Give the default GITHUB_TOKEN write permission to commit and push, comment issues & post new PR
      # Remove the ones you do not need
      contents: write
      issues: write
      pull-requests: write
    steps:
      # Git Checkout
      - name: Checkout Code
        uses: actions/checkout@v6
        with:
          token: ${{ secrets.PAT || secrets.GITHUB_TOKEN }}
          fetch-depth: 0 # If you use VALIDATE_ALL_CODEBASE = true, you can remove this line to improve performances

      # MegaLinter
      - name: MegaLinter
        id: ml
        # You can override MegaLinter flavor used to have faster performances
        # More info at https://megalinter.io/flavors/
        # MAJOR-RELEASE-IMPACTED
        uses: oxsecurity/megalinter@v9
        env:
          # All available variables are described in documentation
          # https://megalinter.io/configuration/
          VALIDATE_ALL_CODEBASE: ${{ github.event_name == 'push' && github.ref == 'refs/heads/main' }} # Validates all source when push on main, else just the git diff with main. Override with true if you always want to lint all sources
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          # ADD YOUR CUSTOM ENV VARIABLES HERE OR DEFINE THEM IN A FILE .mega-linter.yml AT THE ROOT OF YOUR REPOSITORY
          # DISABLE: COPYPASTE,SPELL # Uncomment to disable copy-paste and spell checks

      # Upload MegaLinter artifacts
      - name: Archive production artifacts
        if: success() || failure()
        uses: actions/upload-artifact@v7
        with:
          name: MegaLinter reports
          include-hidden-files: "true"
          path: |
            megalinter-reports
            mega-linter.log

      # Create pull request if applicable (for now works only on PR from same repository, not from forks)
      - name: Create Pull Request with applied fixes
        id: cpr
        if: steps.ml.outputs.has_updated_sources == 1 && (env.APPLY_FIXES_EVENT == 'all' || env.APPLY_FIXES_EVENT == github.event_name) && env.APPLY_FIXES_MODE == 'pull_request' && (github.event_name == 'push' || github.event.pull_request.head.repo.full_name == github.repository) && !contains(github.event.head_commit.message, 'skip fix')
        uses: peter-evans/create-pull-request@v7
        with:
          token: ${{ secrets.PAT || secrets.GITHUB_TOKEN }}
          commit-message: "[MegaLinter] Apply linters automatic fixes"
          title: "[MegaLinter] Apply linters automatic fixes"
          labels: bot
      - name: Create PR output
        if: steps.ml.outputs.has_updated_sources == 1 && (env.APPLY_FIXES_EVENT == 'all' || env.APPLY_FIXES_EVENT == github.event_name) && env.APPLY_FIXES_MODE == 'pull_request' && (github.event_name == 'push' || github.event.pull_request.head.repo.full_name == github.repository) && !contains(github.event.head_commit.message, 'skip fix')
        run: |
          echo "Pull Request Number - ${{ steps.cpr.outputs.pull-request-number }}"
          echo "Pull Request URL - ${{ steps.cpr.outputs.pull-request-url }}"

      # Push new commit if applicable (for now works only on PR from same repository, not from forks)
      - name: Prepare commit
        if: steps.ml.outputs.has_updated_sources == 1 && (env.APPLY_FIXES_EVENT == 'all' || env.APPLY_FIXES_EVENT == github.event_name) && env.APPLY_FIXES_MODE == 'commit' && github.ref != 'refs/heads/main' && (github.event_name == 'push' || github.event.pull_request.head.repo.full_name == github.repository) && !contains(github.event.head_commit.message, 'skip fix')
        run: sudo chown -Rc $UID .git/
      - name: Commit and push applied linter fixes
        if: steps.ml.outputs.has_updated_sources == 1 && (env.APPLY_FIXES_EVENT == 'all' || env.APPLY_FIXES_EVENT == github.event_name) && env.APPLY_FIXES_MODE == 'commit' && github.ref != 'refs/heads/main' && (github.event_name == 'push' || github.event.pull_request.head.repo.full_name == github.repository) && !contains(github.event.head_commit.message, 'skip fix')
        uses: stefanzweifel/git-auto-commit-action@v7
        with:
          branch: ${{ github.event.pull_request.head.ref || github.head_ref || github.ref }}
          commit_message: "[MegaLinter] Apply linters fixes"
          commit_user_name: megalinter-bot
          commit_user_email: 129584137+megalinter-bot@users.noreply.github.com

GitLab CI

Create or update .gitlab-ci.yml file at the root of your repository

# MegaLinter GitLab CI job configuration file
# More info at https://megalinter.io/

mega-linter:
  stage: test
  # You can override MegaLinter flavor used to have faster performances
  # More info at https://megalinter.io/flavors/
  image: oxsecurity/megalinter:v9
  script: [ "true" ] # if script: ["true"] doesn't work, you may try ->  script: [ "/bin/bash /entrypoint.sh" ]
  variables:
    # All available variables are described in documentation
    # https://megalinter.io/configuration/
    DEFAULT_WORKSPACE: $CI_PROJECT_DIR
    # ADD YOUR CUSTOM ENV VARIABLES HERE TO OVERRIDE VALUES OF .mega-linter.yml AT THE ROOT OF YOUR REPOSITORY
  artifacts:
    when: always
    paths:
      - megalinter-reports
    expire_in: 1 week

Create a Gitlab access token and define it in a variable GITLAB_ACCESS_TOKEN_MEGALINTER in the project CI/CD masked variables. Make sure your token (e.g. if a project token) as the appropriate role for commenting a merge request (at least developer).

Azure Pipelines

Use the following Azure Pipelines YAML template

You can configure a build validation branch policy against a single repository or across all repositories. If you configure across all repositories then your pipeline is stored in a central repository.

Single Repository

Add the following to an azure-pipelines.yaml file within your code repository:

  # Run MegaLinter to detect linting and security issues
  - job: MegaLinter
    pool:
      vmImage: ubuntu-latest
    steps:
      # Checkout repo
      - checkout: self

      # Pull MegaLinter docker image
      - script: docker pull oxsecurity/megalinter:v9
        displayName: Pull MegaLinter

      # Run MegaLinter
      - script: |
          docker run -v $(System.DefaultWorkingDirectory):/tmp/lint \
            --env-file <(env | grep -e SYSTEM_ -e BUILD_ -e TF_ -e AGENT_) \
            -e SYSTEM_ACCESSTOKEN=$(System.AccessToken) \
            -e GIT_AUTHORIZATION_BEARER=$(System.AccessToken) \
            oxsecurity/megalinter:v9
        displayName: Run MegaLinter

      # Upload MegaLinter reports
      - task: PublishPipelineArtifact@1
        condition: succeededOrFailed()
        displayName: Upload MegaLinter reports
        inputs:
          targetPath: "$(System.DefaultWorkingDirectory)/megalinter-reports/"
          artifactName: MegaLinterReport

Central Repository

Add the following to an azure-pipelines.yaml file within a separate repository, for example a 'MegaLinter' repository:

# Run MegaLinter to detect linting and security issues

trigger: none

pool:
  vmImage: ubuntu-latest

variables:
  repoName: $[ replace(split(variables['System.PullRequest.SourceRepositoryURI'], '/')[6], '%20', ' ') ]

steps:
  # Checkout triggering repo
  - checkout: git://$(System.TeamProject)/$(repoName)@$(System.PullRequest.SourceBranch)
    displayName: Checkout Triggering Repository

  # Pull MegaLinter docker image
  - script: docker pull oxsecurity/megalinter:v9
    displayName: Pull MegaLinter

  # Run MegaLinter
  - script: |
      docker run -v $(System.DefaultWorkingDirectory):/tmp/lint \
        --env-file <(env | grep -e SYSTEM_ -e BUILD_ -e TF_ -e AGENT_) \
        -e SYSTEM_ACCESSTOKEN=$(System.AccessToken) \
        -e GIT_AUTHORIZATION_BEARER=$(System.AccessToken) \
        oxsecurity/megalinter:v9
    displayName: Run MegaLinter

  # Upload MegaLinter reports
  - task: PublishPipelineArtifact@1
    condition: succeededOrFailed()
    displayName: MegaLinter Report
    inputs:
      targetPath: $(System.DefaultWorkingDirectory)/megalinter-reports/
      artifactName: MegaLinterReport

Pull Request Comments

To enable Pull Request comments, follow the configuration instructions.

Note: If your pipelines run on Azure DevOps but your source code is hosted on GitHub, and you want status reports to appear on GitHub, you must provide additional repository information to the pipeline. See this example for guidance.

Detailed Tutorial

You can also follow this detailed tutorial by DonKoning.

Bitbucket Pipelines

Create a bitbucket-pipelines.yml file at the root of your repository.
Copy and paste the following template or add the step to your existing pipeline.

image: atlassian/default-image:3
pipelines:
  default:
    - parallel:
      - step:
          name: Run MegaLinter
          image: oxsecurity/megalinter:v9
          script:
            - export DEFAULT_WORKSPACE=$BITBUCKET_CLONE_DIR && bash /entrypoint.sh
          artifacts:
            -  megalinter-reports/**

Jenkins

Add the following stage to your Jenkinsfile.

You may activate the File.io reporter or Email reporter to access detailed logs and fixed sources.

// Lint with MegaLinter: https://megalinter.io/
stage('MegaLinter') {
    agent {
        docker {
            image 'oxsecurity/megalinter:v9'
            args "-u root -e VALIDATE_ALL_CODEBASE=true -v ${WORKSPACE}:/tmp/lint --entrypoint=''"
            reuseNode true
        }
    }
    steps {
        sh '/entrypoint.sh'
    }
    post {
        always {
            archiveArtifacts allowEmptyArchive: true, artifacts: 'mega-linter.log,megalinter-reports/**/*', defaultExcludes: false, followSymlinks: false
        }
    }
}

CloudBees has a helpful tutorial about how to use MegaLinter with Jenkins!

Concourse

Pipeline step

Use the following job step in your pipeline template.

Note: Make sure you have a job.plan.get step that retrieves the repo containing your repository, as shown in the example.

---

  - name: linting
    plan:
      - get: repo
      - task: linting
        config:
          platform: linux
          image_resource:
            type: docker-image
            source:
              repository: oxsecurity/megalinter
              tag: v9
          inputs:
            - name: repo
          run:
            path: bash
            args:
            - -cxe
            - |
              cd repo
              export DEFAULT_WORKSPACE=$(pwd)
              bash -ex /entrypoint.sh
              ## doing this because concourse doesn't work as other CI systems
          # params:
            # PARALLEL: true
            # DISABLE: SPELL
            # APPLY_FIXES: all
            # DISABLE_ERRORS: true
            # VALIDATE_ALL_CODEBASE: true

Use it as a reusable task

Create a reusable Concourse task that can be used with multiple pipelines.

Create task file task-linting.yaml

---
platform: linux
image_resource:
  type: docker-image
  source:
    repository: oxsecurity/megalinter
    tag: v9

inputs:
- name: repo

## uncomment this if you want reports as task output
# output:
# - name: reports
#   path: repo/megalinter-reports

run:
  path: bash
  args:
  - -cxe
  - |
    cd repo
    export DEFAULT_WORKSPACE=$(pwd)
    bash -ex /entrypoint.sh

Use that task-linting.yaml task in your pipeline.

Note:

Make sure task-linting.yaml is available in the repo input at the repository root.
Task output is not shown here.

resources:

  - name: linting
    plan:
      - get: repo
      - task: linting
        file: repo/task-linting.yaml
        # params:
        #   PARALLEL: true
        #   DISABLE: SPELL
        #   APPLY_FIXES: all
        #   DISABLE_ERRORS: true
        #   VALIDATE_ALL_CODEBASE: true

Drone CI

Warning: Drone CI support is experimental and is undergoing significant modifications (see issue #2047).

Create a .drone.yml file on the root directory of your repository
Copy and paste the following template:

kind: pipeline
type: docker
name: MegaLinter

workspace:
  path: /tmp/lint

steps:

- name: megalinter
  image: oxsecurity/megalinter:v9
  environment:
    DEFAULT_WORKSPACE: /tmp/lint

This uses the Drone CI Docker runner, so you need to install and configure it beforehand on your Drone CI server.

(Optional) Adjusting trigger rules

The Drone CI workflow should trigger automatically for most scenarios (push, pull request, sync…). However, you can optionally change this behavior by modifying the trigger. For example:

kind: pipeline
type: docker
name: MegaLinter

workspace:
  path: /tmp/lint

steps:

- name: megalinter
  image: oxsecurity/megalinter:v9
  environment:
    DEFAULT_WORKSPACE: /tmp/lint

trigger:
  event:
  - push

The workflow above triggers only on push, and not in other situations. For more information about configuring Drone CI trigger rules, see the documentation.

Docker container

You can also run MegaLinter with its Docker container. Execute this command:

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock:rw -v $(pwd):/tmp/lint:rw oxsecurity/megalinter:v9

No extra arguments are needed; however, MegaLinter will lint all files inside the /tmp/lint folder. You may need to configure your tool of choice to use /tmp/lint as its workspace. This can be changed:

Example:

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock:rw -v $(pwd):/example/folder:rw oxsecurity/megalinter:v9

Run MegaLinter locally

Use mega-linter-runner to run MegaLinter locally with the same configuration defined in your .mega-linter.yml file.

See the mega-linter-runner installation instructions.

Example:

npx mega-linter-runner --flavor salesforce -e "'ENABLE=DOCKERFILE,MARKDOWN,YAML'" -e 'SHOW_ELAPSED_TIME=true'

Note: You can also use this command line in your custom CI/CD pipelines.

Configuration

.mega-linter.yml file

MegaLinter configuration variables are defined in a .mega-linter.yml file at the root of the repository or with environment variables. You can see an example config file in this repo: .mega-linter.yml.

Configuration is assisted with autocompletion and validation in most commonly used IDEs, thanks to the JSON schema stored on schemastore.org.

VS Code: You need an extension like Red Hat YAML.
IntelliJ IDEA family: Autocompletion is supported natively.

You can also define variables as environment variables.

If a variable exists in both ENV and the .mega-linter.yml file, priority is given to the ENV variable.

Common variables

ENV VAR	Default Value	Notes
ADDITIONAL_EXCLUDED_DIRECTORIES	[]	List of additional excluded directory basenames. They're excluded at any nested level.
APPLY_FIXES	`none`	Activates formatting and autofix (more info)
CLEAR_REPORT_FOLDER	`false`	Flag to clear files from report folder (usually megalinter-reports) before starting the linting process
CONFIG_PROPERTIES_TO_APPEND	[]	List of configuration properties to append their values (instead of replacing them) in case of using EXTENDS.
DEFAULT_BRANCH	`HEAD`	The name of the repository's default branch, useful if you use VALIDATE_ALL_CODEBASE=false
DEFAULT_WORKSPACE	`/tmp/lint`	The location containing files to lint if you are running locally.
DISABLE_ERRORS	`false`	Flag to have the linter complete with exit code 0 even if errors were detected.
DISABLE		List of disabled descriptors keys (more info)
DISABLE_LINTERS		List of disabled linters keys (more info)
DISABLE_ERRORS_LINTERS		List of enabled but not blocking linters keys. All linters not in this list will be not blocking (more info)
ENABLE_ERRORS_LINTERS		List of enabled and blocking linters keys (more info)
ENABLE		List of enabled descriptors keys (more info)
ENABLE_LINTERS		List of enabled linters keys (more info)
EXCLUDED_DIRECTORIES	[…many values…]	List of excluded directory basenames. They're excluded at any nested level.
EXTENDS		Base `mega-linter.yml` config file(s) to extend local configuration from. Can be a single URL or a list of `.mega-linter.yml` config files URLs. Later files take precedence.
FAIL_IF_MISSING_LINTER_IN_FLAVOR	`false`	If set to `true`, MegaLinter fails if a linter is missing in the selected flavor
FAIL_IF_UPDATED_SOURCES	`false`	If set to `true`, MegaLinter fails if a linter or formatter has autofixed sources, even if there are no errors
FILTER_REGEX_EXCLUDE	`none`	Regular expression defining which files will be excluded from linting (more info) .ex: `.src/test.`)
FILTER_REGEX_INCLUDE	`all`	Regular expression defining which files will be processed by linters (more info) .ex: `.src/.`)
FLAVOR_SUGGESTIONS	`true`	Provides suggestions about different MegaLinter flavors to use to improve runtime performances
FORMATTERS_DISABLE_ERRORS	`true`	Formatter errors will be reported as errors (not warnings) if this variable is set to `false`.
GIT_AUTHORIZATION_BEARER		If set, calls git with `Authorization: Bearer`+value
GITHUB_WORKSPACE		Base directory for `REPORT_OUTPUT_FOLDER`, for user-defined linter rules location, for location of linted files if `DEFAULT_WORKSPACE` isn't set
IGNORE_GENERATED_FILES	`false`	If set to `true`, MegaLinter will skip files containing `@generated` marker but without `@not-generated` marker (more info at https://generated.at)
IGNORE_GITIGNORED_FILES	`true`	If set to `true`, MegaLinter will skip files ignored by Git using the `.gitignore` file.
JAVASCRIPT_DEFAULT_STYLE	`standard`	Javascript default style to check/apply. `standard`,`prettier`
LINTER_RULES_PATH	`.github/linters`	Directory for all linter configuration rules. Can be a local folder or a remote URL (e.g., `https://raw.githubusercontent.com/some_org/some_repo/mega-linter-rules`).
LOG_FILE	`mega-linter.log`	The file name for outputting logs. All output is sent to the log file regardless of `LOG_LEVEL`. Use `none` to not generate this file.
LOG_LEVEL	`INFO`	How much output the script will generate to the console. One of `INFO`, `DEBUG`, `WARNING` or `ERROR`.
MARKDOWN_DEFAULT_STYLE	`markdownlint`	Markdown default style to check/apply. `markdownlint`, `remark-lint`, `rumdl`
MEGALINTER_CONFIG	`.mega-linter.yml`	Name of MegaLinter configuration file. Can be defined remotely, in that case set this environment variable with the remote URL of `.mega-linter.yml` config file
MEGALINTER_FILES_TO_LINT	[]	Comma-separated list of files to analyze. Using this variable will bypass other file listing methods
PARALLEL	`true`	Process linters in parallel to improve overall MegaLinter performance. If true, linters of same language or formats are grouped in the same parallel process to avoid lock issues if fixing the same files
PARALLEL_PROCESS_NUMBER		All available cores are used by default. If there are too many, decrease the number of used cores to enhance performance (example: `4`).
PLUGINS	[]	List of plugin urls to install and run during MegaLinter run
POST_COMMANDS	[]	Custom bash commands to run after linters
PRE_COMMANDS	[]	Custom bash commands to run before linters
PRINT_ALPACA	`true`	Enable printing alpaca image to console
PRINT_ALL_FILES	`false`	Display all files analyzed by the linter instead of only the number.
PYTHON_DEFAULT_STYLE	`black`	Python default style to check/apply. `black`,`ruff`
REPORT_OUTPUT_FOLDER	`${GITHUB_WORKSPACE}/megalinter-reports`	Directory for generating report files. Set to `none` to skip generating reports.
SECURED_ENV_VARIABLES	[]	Additional list of secured environment variables to hide when calling linters.
SECURED_ENV_VARIABLES_DEFAULT	MegaLinter & CI platforms sensitive variables	List of secured environment variables to hide when calling linters. Default list. This is not recommended to override this variable, use SECURED_ENV_VARIABLES
SHOW_ELAPSED_TIME	`false`	Displays elapsed time in reports
SHOW_SKIPPED_LINTERS	`true`	Displays all disabled linters MegaLinter could have run.
SKIP_CLI_LINT_MODES	[]	Comma-separated list of cli_lint_modes. To use if you want to skip linters with some CLI lint modes (ex: `file,project`). Available values: `file`,`cli_lint_mode`,`project`.
SKIP_LINTER_OUTPUT_SANITIZATION	`false`	By default, MegaLinter sanitizes the output of every external command using Gitleaks public rules. If you are on a private and secured repo, you can improve performances by setting this variable to `true`, but it will mean that if a linter output contains a secret, it will be visible in log files
TYPESCRIPT_DEFAULT_STYLE	`standard`	Typescript default style to check/apply. `standard`,`prettier`
VALIDATE_ALL_CODEBASE	`true`	Will parse the entire repository and find all files to validate across all types. NOTE: When set to `false`, only new or edited files will be parsed for validation.

Activation and deactivation

MegaLinter has all linters enabled by default, but allows enabling or disabling specific ones.

If ENABLE isn't set, all descriptors are activated by default. If set, all linters of listed descriptors are activated by default.
If ENABLE_LINTERS is set, only the listed linters are processed.
If DISABLE is set, the linters in the listed descriptors are skipped.
If DISABLE_LINTERS is set, the listed linters are skipped.
If DISABLE_ERRORS_LINTERS is set, the listed linters will run, but if errors are found, they will be considered non-blocking.
If ENABLE_ERRORS_LINTERS is set, only the linters in this list will be considered blocking.

Examples:

Run all javascript and groovy linters except STANDARD javascript linter. DevSkim errors will be non-blocking

ENABLE: JAVASCRIPT,GROOVY
DISABLE_LINTERS: JAVASCRIPT_STANDARD
DISABLE_ERRORS_LINTERS: REPOSITORY_DEVSKIM

Run all matching linters but only trivy is blocking

ENABLE_ERRORS_LINTERS: REPOSITORY_TRIVY

Run all linters except PHP linters (PHP_BUILTIN, PHP_PHPCS, PHP_PHPSTAN, PHP_PSALM)

DISABLE: PHP

Run all linters except PHP_PHPSTAN and PHP_PSALM linters

DISABLE_LINTERS:
  - PHP_PHPSTAN
  - PHP_PSALM

Filter linted files

If you need to lint only a folder or exclude some files from linting, you can use the optional environment parameters FILTER_REGEX_INCLUDE and FILTER_REGEX_EXCLUDE. You can apply filters to a single linter by defining the variables <LINTER_KEY>_FILTER_REGEX_INCLUDE and <LINTER_KEY>_FILTER_REGEX_EXCLUDE.

Examples:

Lint only src folder: FILTER_REGEX_INCLUDE: (src/)
Don't lint files inside test and example folders: FILTER_REGEX_EXCLUDE: (test/|examples/)
Don't lint javascript files inside test folder: FILTER_REGEX_EXCLUDE: (test/.*\.js)

Warning: Not applicable with linters using CLI lint mode project (see details).

You can also use variable ADDITIONAL_EXCLUDED_DIRECTORIES to add more excluded directories

Example:

ADDITIONAL_EXCLUDED_DIRECTORIES:
  - .wireit
  - dist
  - build
  - vendor

Apply fixes

MegaLinter can apply fixes provided by linters. To use this capability, you need three environment variables defined at the top level.

APPLY_FIXES: all to apply fixes of all linters, or a list of linter keys (ex: JAVASCRIPT_ES,MARKDOWN_MARKDOWNLINT)

Only for the GitHub Actions workflow file, if you use it:

APPLY_FIXES_EVENT: all, push, pull_request, none (use none in case of use of Updated sources reporter)
APPLY_FIXES_MODE: commit to create a new commit and push it on the same branch, or pull_request to create a new PR targeting the branch.

Apply fixes issues

You may see GitHub permission errors, or workflows not running on the new commit.

To solve these issues, apply one of the following solutions.

Method 1: The most secured
- Create a Fine-Grained Personal Access Token, scoped only to your repository and with Contents: Read/Write, then copy the PAT value
- Define environment secret variable named PAT on your repository, and paste the PAT value
- Update your GitHub Actions workflow to add the environment name

-- Method 2: Easier, but any contributor with write access can see your Personal Access Token, so use it only on private repositories.

Create a Classic Personal Access Token, then copy the PAT value
Define secret variable named PAT on your repository, and paste the PAT value

Notes

You can use the Updated sources reporter if you don't want fixes to be automatically applied on the Git branch. Instead, download them in a ZIP file and manually extract them into your project.
If used, APPLY_FIXES_EVENT and APPLY_FIXES_MODE cannot be defined in the .mega-linter.yml config file; they must be set as environment variables.
If you use APPLY_FIXES, add the following line to your .gitignore file:

megalinter-reports/

Linter specific variables

See variables related to a single linter behavior in linters documentations

Pre-commands

MegaLinter can run custom commands before running linters (for example, installing a plugin required by one of the linters you use).

Example in .mega-linter.yml config file

PRE_COMMANDS:
  - command: npm install eslint-plugin-whatever
    cwd: root        # Will be run at the root of the MegaLinter Docker image
    secured_env: true  # True by default. If set to false, no global variables will be hidden (for example, if you need GITHUB_TOKEN)
    run_before_linters: True # Will be run before the execution of the linters themselves; required for npm/pip commands that cannot be run in parallel
  - command: echo "pre-test command has been called"
    cwd: workspace   # Will be run at the root of the workspace (usually your repository root)
    continue_if_failed: False  # Will stop the process if the command fails (return code > 0)
  - command: pip install flake8-cognitive-complexity
    venv: flake8 # Will be run within the flake8 Python virtualenv. There is one virtualenv per Python-based linter, with the same name
  - command: export MY_OUTPUT_VAR="my output var" && export MY_OUTPUT_VAR2="my output var2"
    output_variables: ["MY_OUTPUT_VAR","MY_OUTPUT_VAR2"] # Will collect the values of output variables and update MegaLinter's own ENV context
  - command: echo "Some command called before loading MegaLinter plugins"
    cwd: workspace   # Will be run at the root of the workspace (usually your repository root)
    continue_if_failed: False  # Will stop the process if the command fails (return code > 0)
    tag: before_plugins # Tag indicating that the command will be run before loading plugins
  - command: echo "Some command called after running MegaLinter linters"
    run_after_linters: True # Will be run after the execution of the linters themselves

Property	Description	Default value
command	Command line to run	Mandatory
cwd	Directory where to run the command (`workspace` or `root`)	`workspace`
run_before_linters	If set to `true`, runs the command before the execution of the linters themselves, required for npm/pip commands that cannot be run in parallel	`false`
run_after_linters	If set to `true`, runs the command after the execution of the linters themselves	`false`
secured_env	Apply filtering of secured environment variables before calling the command (default true). Be careful if you disable it!	`true`
continue_if_failed	If set to `false`, stop the MegaLinter process in case of command failure	`true`
venv	If set, runs the command in the related Python venv
output_variables	ENV variables to read from output after running the commands, and store in MegaLinter's ENV context so they can be reused in subsequent commands	`[]`
tag	Tag defining at which command entry point the command will be run (available tags: `before_plugins`)

Post-commands

MegaLinter can run custom commands after running linters (for example, running additional tests).

Example in .mega-linter.yml config file

POST_COMMANDS:
  - command: npm run test
    cwd: "workspace"   # Will be run at the root of the workspace (usually your repository root)
    continue_if_failed: False  # Will stop the process if the command fails (return code > 0)

Environment variables security

Secured env variables

MegaLinter runs in a Docker image and calls the linters via the command line to gather their results.

If you run it from your CI/CD pipelines, the Docker image may have access to your environment variables, which can contain secrets defined in CI/CD variables.

As it can be complicated to fully trust the authors of all open-source linters, MegaLinter removes variables from the environment used to call linters.

Thanks to this feature, you only need to trust MegaLinter and its internal Python dependencies; there is no need to trust all the linters that are used.

You can add secured variables to the default list using the configuration property SECURED_ENV_VARIABLES in .mega-linter.yml or as an environment variable (priority is given to ENV variables over the .mega-linter.yml property).

Values can be:

String (ex: MY_SECRET_VAR)
Regular Expression (ex: (MY.*VAR))

Environment variables are secured for each command line called (linters, plugins, SARIF formatter, etc.) except for PRE_COMMANDS, and only if you define secured_env: false in the command.

Secured configuration examples

Example of adding extra secured variables in .mega-linter.yml:

SECURED_ENV_VARIABLES:
  - MY_SECRET_TOKEN
  - ANOTHER_VAR_CONTAINING_SENSITIVE_DATA
  - OX_API_KEY
  - (MY.*VAR)  # Regex format

Example of adding extra secured variables in CI variables, so they cannot be overridden in .mega-linter.yml:

SECURED_ENV_VARIABLES=MY_SECRET_TOKEN,ANOTHER_VAR_CONTAINING_SENSITIVE_DATA,OX_API_KEY

Default secured variables

If you override SECURED_ENV_VARIABLES_DEFAULT, it replaces the default list, so it's better to only define SECURED_ENV_VARIABLES to add items to the default list.

SECURED_ENV_VARIABLES_DEFAULT contains exact names and (regular expressions) matching patterns for commonly used sensitive environment variables:

PAT
GIT_AUTHORIZATION_BEARER
GITLAB_CUSTOM_CERTIFICATE
(USERNAME)
(PASSWORD)
(TOKEN)
(SFDX_CLIENT_ID_.*)
(SFDX_CLIENT_KEY_.*)

Unhide variables for linters

You can configure exceptions for a specific linter by defining (linter-key)_UNSECURED_ENV_VARIABLES.

Variable names in this list won't be hidden from the linter commands.

TERRAFORM_TFLINT_UNSECURED_ENV_VARIABLES:
  - GITHUB_TOKEN # Can contain string only, not regex

CLI lint mode

Each linter is preconfigured to use a default lint mode, which is visible in the MegaLinter documentation (example). The possible values are:

list_of_files: The linter is called only once, and passed a list of all the files to be processed
project: The linter is called only once, from the root folder of the repository, and it scans for the files to process, as no file names are provided to it
file: The linter is called once per file, which hurts performance

You can override the CLI_LINT_MODE by using a configuration variable for each linter (see the linters documentation).

Linters that default to the file lint mode cannot be overridden to use the list_of_files lint mode.
Linters that default to the project lint mode cannot be overridden to use either the list_of_files or file lint modes.

Allowing file or list_of_files to be overridden to project is mostly for workarounds. For example, some linters have a problem finding their config file when the current folder isn't the repository root.

Special considerations:

Linters that are configured to use the project lint mode ignore variables like FILTER_REGEX_INCLUDE and FILTER_REGEX_EXCLUDE, as they are not passed a list of files to lint. For those linters, you must check their documentation to see if a linter can be configured to ignore specific files. For example, the Secretlint linter ignores files listed in ~/.secretlintignore by default, or it can be configured to instead ignore files listed in ~/.gitignore by setting REPOSITORY_SECRETLINT_ARGUMENTS to --secretlintignore .gitignore.

Reporters

MegaLinter can generate various reports that you can activate or deactivate and customize.

Reporter	Description	Default
Text files	Generates One log file by linter + suggestions for fixes that can not be automated	Active
SARIF (beta)	Generates an aggregated SARIF output file	Inactive
GitHub Pull Request comments	MegaLinter posts a comment on the PR with a summary of lint results, and links to detailed logs	Active if GitHub Action
Gitlab Merge Request comments	Mega-Linter posts a comment on the MR with a summary of lint results, and links to detailed logs	Active if in Gitlab CI
Azure Pipelines Pull Request comments	Mega-Linter posts a comment on the PR with a summary of lint results, and links to detailed logs	Active if in Azure Pipelines
Bitbucket Pull Request comments	Mega-Linter posts a comment on the PR with a summary of lint results, and links to detailed logs	Active if in Bitbucket CI
API (Grafana)	Sends logs and metrics to Grafana endpoint (Loki / Prometheus)	Inactive
Updated sources	Zip containing all formatted and autofixed sources so you can extract them in your repository	Active
IDE Configuration	Apply MegaLinter configuration in your local IDE with linter config files and IDE extensions	Active
GitHub Status	One GitHub status by linter on the PR, with links to detailed logs	Active if GitHub Action
File.io	Send reports on file.io so you can access them with a simple hyperlink provided at the end of console log	Inactive
JSON	Generates a JSON output report file	Inactive
Email	Receive all reports on your e-mail, if you can not use artifacts	Active
TAP files	One file by linter following Test Anything Protocol format	Active
Console	Execution logs visible in console with summary table and links to other reports at the end	Active
Markdown Summary	Generates a Markdown summary report file	Inactive

Flavors

To improve run performance, we provide flavored MegaLinter images containing only the linters related to a project type.

When using the default MegaLinter, if a MegaLinter flavor would cover all your project requirements, a message is added in the logs.
If your project uses a MegaLinter flavor that doesn't cover linter requirements, an error message will be thrown with instructions on how to solve the issue.

The following table doesn't display docker pulls from MegaLinter v4 & v5 images.

Flavor	Description	Embedded linters
all	Default MegaLinter Flavor	134
c_cpp	Optimized for pure C/C++ projects	58
ci_light	Optimized for CI items (Dockerfile, Jenkinsfile, JSON/YAML schemas,XML	22
cupcake	MegaLinter for the most commonly used languages	91
documentation	MegaLinter for documentation projects	51
dotnet	Optimized for C, C++, C# or VB based projects	66
dotnetweb	Optimized for C, C++, C# or VB based projects with JS/TS	75
formatters	Contains only formatters	19
go	Optimized for GO based projects	53
java	Optimized for JAVA based projects	56
javascript	Optimized for JAVASCRIPT or TYPESCRIPT based projects	61
php	Optimized for PHP based projects	56
python	Optimized for PYTHON based projects	68
ruby	Optimized for RUBY based projects	52
rust	Optimized for RUST based projects	52
salesforce	Optimized for Salesforce based projects	58
security	Optimized for security	25
swift	Optimized for SWIFT based projects	52
terraform	Optimized for TERRAFORM based projects	56

If you need a new flavor, post an issue 😉

You can also generate your own custom flavors to include exactly the linters you need in your MegaLinter Docker image.

Badge

You can show the MegaLinter status with a badge in your repository README.

If your main branch is named master, replace main with master in the URLs.

Markdown

Format

[![MegaLinter](https://github.com/<OWNER>/<REPOSITORY>/workflows/MegaLinter/badge.svg?branch=main)](https://github.com/<OWNER>/<REPOSITORY>/actions?query=workflow%3AMegaLinter+branch%3Amain)

Example

[![MegaLinter](https://github.com/nvuillam/npm-groovy-lint/workflows/MegaLinter/badge.svg?branch=main)](https://github.com/nvuillam/npm-groovy-lint/actions?query=workflow%3AMegaLinter+branch%3Amain)

reStructuredText

Format

.. |MegaLinter yes| image:: https://github.com/<OWNER>/<REPOSITORY>/workflows/MegaLinter/badge.svg?branch=main
   :target: https://github.com/<OWNER>/<REPOSITORY>/actions?query=workflow%3AMegaLinter+branch%3Amain

Example

.. |MegaLinter yes| image:: https://github.com/nvuillam/npm-groovy-lint/workflows/MegaLinter/badge.svg?branch=main
   :target: https://github.com/nvuillam/npm-groovy-lint/actions?query=workflow%3AMegaLinter+branch%3Amain

Note: IF you did not use MegaLinter as GitHub Action name, please read GitHub Actions Badges documentation{target=_blank}

Plugins

For performance and security reasons, we cannot embed every linter in MegaLinter.

But our core architecture allows building and publishing MegaLinter plugins!

External Plugins Catalog

Name	Description	Author	Raw URL
jupyfmt	The uncompromising Jupyter notebook formatter	Kim Philipp Jablonski	Descriptor
linkcheck	Plugin to check and validate markdown links exist and working	Shiran Rubin	Descriptor
nitpick	Command-line tool and flake8 plugin to enforce the same settings across multiple language-independent projects	W. Augusto Andreoli	Descriptor
mustache	Plugin to validate Logstash pipeline definition files using mustache	Yann Jouanique	Descriptor
salt-lint	Checks Salt State files (SLS) for best practices and behavior that could potentially be improved.	Joachim Grimm	Descriptor
docker-compose-linter	Plugin to lint docker-compose files	Wesley Dean	Descriptor
repolinter	Plugin to run TODO Group's repolinter to look for repository best practices	Wesley Dean	Descriptor
j2lint	Plugin to lint Jinja2 files	Wesley Dean	Descriptor
fmlint	Plugin to lint YAML frontmatter in Markdown documents	Wesley Dean	Descriptor

Note: Using an external plugin means you trust its author.

Submit a Pull Request if you want your plugin to appear here :)

Use external plugins

Add plugin URLs in the PLUGINS property of .mega-linter.yml. URLs must either begin with "https://" or take the form of "file://<path>", where <path> points to a valid plugin descriptor file.

Note: Both <path> and the default mount directory (/tmp/lint/<path>) will be checked for a valid descriptor.

Example

PLUGINS:
  - https://raw.githubusercontent.com/kpj/jupyfmt/master/mega-linter-plugin-jupyfmt/jupyfmt.megalinter-descriptor.yml
  - file://.automation/test/mega-linter-plugin-test/test.megalinter-descriptor.yml

Create your own plugin

You can implement your own descriptors and load them as plugins during MegaLinter runtime.

Descriptor format is exactly the same as MegaLinter embedded ones (see JSON schema documentation)
Plugin descriptor files must be named **.megalinter-descriptor.yml and conform to the MegaLinter JSON Schema
Plugins must be hosted in a URL containing **/mega-linter-plugin-**/
File URLs must conform to the same directory and file naming criteria as defined above.

Limitations

For now, the only install attributes managed are dockerfile instructions starting by RUN

They talk about MegaLinter

English articles

Article	Author
Looking for the best CI/CD Pipeline Linting Tool? Try MegaLinter!{target=_blank}	Seasoned Developer{target=_blank}
Integrating MegaLinter to Automate Linting Across Multiple Codebases. A Technical Description{target=_blank}	Thorsten Foltz{target=_blank}
MegaLinter Performance Tuning for Maximum Efficiency{target=_blank}	Wes Dean{target=_blank}
10 MegaLinter Tips and Tricks Unlock its Full Potential{target=_blank}	Wes Dean{target=_blank}
30 Seconds to Setup MegaLinter: Your Go-To Tool for Automated Code Quality{target=_blank}	Peng Cao
Introducing MegaLinter: Streamlining Code Quality Checks Across Multiple Languages{target=_blank}	Cloud Tuned{target=_blank}
Infrastructure as Code GitHub Codespace Template{target=_blank}	Luke Murray{target=_blank}
5 ways MegaLinter upped our DevSecOps game{target=_blank}	Wes Dean{target=_blank}
Achieve Code Consistency: MegaLinter Integration in Azure DevOps{target=_blank}	Don Koning{target=_blank} on Microsoft Tech Community{target=_blank}
MegaLinter in Azure DevOps{target=_blank}	James Cook{target=_blank}
Maximize your code consistency with Megalinter{target=_blank}	Tor Ivar Asbølmo{target=_blank} on codewithme.cloud{target=_blank}
8 Tools to Scan Node.js Applications for Security Vulnerability{target=_blank}	Chandan Kumar{target=_blank} on GeekFlare.com{target=_blank}
Use the Workflows JSON schema in your IDE{target=_blank}	Google Cloud{target=_blank}
Level up your Unity Packages with CI/CD{target=_blank}	RunningMattress{target=_blank}
GitHub Actions: sharing your secrets with third-party actions{target=_blank}	Constantin Bosse{target=_blank} and Stephen Hosom{target=_blank}
Talk about the Kotlin plugins Kover, Ktlint and Detekt. Made for the AmsterdamJUG meetup.{target=_blank}	Simone de Gijt{target=_blank}
Linting - What is all the fluff about?{target=_blank}	Neil Shepard{target=_blank}, University Of Sheffield
How to apply security at the source using GitOps{target=_blank}	Edu Minguez{target=_blank}
How to linter basic things like trailing whitespaces and newlines{target=_blank}	Nicolai Antiferov{target=_blank}
Node.js Coding Standard Tools with MegaLinter on Gitlab CI{target=_blank}	Albion Bame{target=_blank}
Linting a Jekyll blog with MegaLinter{target=_blank}	Alec Johnson{target=_blank}
MegaLinter sells his soul and joins OX Security{target=_blank}	Nicolas Vuillamy{target=_blank}
Limit your technical debt and secure your code base using MegaLinter{target=_blank}	Nicolas Vuillamy{target=_blank}

French articles

Article	Author
MegaLinter{target=_blank}	Stéphane Robert, 3DS OutScale{target=_blank}
MegaLinter: un linter pour les gouverner tous{target=_blank}	Guillaume Arnaud, WeScale{target=_blank}
MegaLinter, votre meilleur ami pour un code de qualité{target=_blank}	Thomas Sanson{target=_blank}

Japanese articles

Article	Author
Try using MegaLinter{target=_blank}	Takashi Minayaga{target=_blank}

Videos

(Brazilian) Qualidade e Segurança em Código com MegaLinter: automatizando análises em MAUI com GitHub Actions, by Canal dotNET

(Brazilian) MegaLinter: Como Automatizar a Qualidade do Código para Todas Plataformas, by Codando TV

How to: Secrets scanning, by Hackitect's playground

How to use MegaLinter with Jenkins, by Darin Pope / Cloudbees

(FR) MegaLinter presentation at DevCon 20 / Programmez Magazine, by Nicolas Vuillamy

Code quality - Ep01 - MegaLinter, one linter to rule them all, by Bertrand Thomas

DevSecOps Webinar using MegaLinter, by 5.15 Technologies{target=_blank}

Ortelius Architecture Meeting, with a review of MegaLinter, by Steve Taylor{target=_blank} from Ortelius

Web Sites

analysis-tools.dev{target=_blank}
awesome-linters{target=_blank}
schemastore.org{target=_blank}
abhith.net{target=_blank}

my-devops-lab.com{target=_blank}

Linters

checkmake{target=_blank}
checkstyle{target=_blank}
clj-kondo{target=_blank}
cljstyle{target=_blank}
cspell{target=_blank}
detekt{target=_blank}
djlint{target=_blank}
dotenv-linter{target=_blank}
editorconfig-checker{target=_blank}
eslint{target=_blank}
eslint-plugin-jsonc{target=_blank}
hadolint{target=_blank}
htmlhint{target=_blank}
jscpd{target=_blank}
kics{target=_blank}
ktlint{target=_blank}
lintr{target=_blank}
npm-groovy-lint{target=_blank}
npm-package-json-lint{target=_blank}
pmd{target=_blank}
rst-lint{target=_blank}
rstcheck{target=_blank}
rubocop{target=_blank}
scalafix{target=_blank}
secretlint{target=_blank}

Frequently Asked Questions

My repo CI already has linters and they're working perfectly, so why do I need MegaLinter?

You can continue using your installed linters and deactivate them in .mega-linter.yml. For example, in a JavaScript project using ESLint, configure MegaLinter with DISABLE: JAVASCRIPT. That way, you will benefit from both your installed linters and other MegaLinter linters checking JSON, YAML, Markdown, Dockerfile, Bash, spelling mistakes, dead URLs…

OK but… how does it work?

MegaLinter is based on Docker images containing either all linters, or a selection of linters if you use a MegaLinter flavor for a project with a specific language or format.

The core architecture does the following:

Initialization
- List all project files:
  - except files in ignored folders (node_modules, etc…)
  - except files not matching FILTER_REGEX_INCLUDE (if defined by user)
  - except files matching FILTER_REGEX_EXCLUDE (if defined by user)
- Collect files for each activated linter, matching their own filtering criteria:
  - file extensions
  - file names
  - file content
  - <descriptor_or_linter_key>_FILTER_REGEX_INCLUDE (if defined by user)
  - <descriptor_or_linter_key>_FILTER_REGEX_EXCLUDE (if defined by user)
Linting
- Parallelly, for each linter with matching files:
  - Call the linter on matching files (or the whole project for some linters like copy-paste detector)
  - Call activated linter-level reporters (GitHub Status Reporter…)
Finalization
- Call activated global level reporters (GitHub Pull Request Comment Reporter, File.io Reporter, Email Reporter…)
- Manage return code:
  - 0 if no error (or only non blocking errors if user defined DISABLE_ERRORS or <descriptor_or_linter_key>_DISABLE_ERRORS)
  - 1 if errors

How to contribute

Contributions to MegaLinter are very welcome: the more we are, the stronger MegaLinter becomes! Please follow Contributing Guide

To help, you can also:

⭐ Star the repository
🍺 Offer a beer!
report problems and request new features
share on twitter{target=_blank}

Special thanks

Maintainers

MegaLinter wouldn't be what it is without its great team of maintainers!

Contributors

Open-source teams

MegaLinter obviously would not exist without its linters and libraries: many thanks to all the dedicated open-source teams maintaining these awesome linters!

Super-Linter team

MegaLinter has been built on the ashes of a rejected Pull Request{target=_blank} on GitHub Super-Linter{target=_blank}.

Even if I disagree with their decision to remain in Bash, the core team has always been nice and supportive during the time I was a Super-Linter contributor{target=_blank} :)

License

GNU Affero General Public License

MegaLinter vs Super-Linter

The hard fork of Super-Linter to Python isn't just a language switch: Python's flexibility and libraries enabled many additional features described below.

Security

MegaLinter hides many environment variables when calling the linters.

That way you need to trust only MegaLinter core code with your secrets, not the 100+ embedded linters !

Performance

MegaLinter flavors allow using smaller Docker images, reducing pull time.
Thanks to Python multiprocessing, linters are run in parallel, which is much faster than Super-Linter's Bash script that runs all linters sequentially.
When the linter allows it, call it once with N files, instead of calling it N times with one file.

More languages and formats linted

C, C++, Copy-Paste detection, Credentials, GraphQL, JSON & YAML with JSON schemas, Markdown tables formatting, Puppet, reStructuredText, Rust, Scala, Spell checker, Swift, Visual Basic .NET …

Automatically apply formatting and fixes

MegaLinter can automatically apply fixes performed by linters and push them to the same branch, or create a Pull Request that you can validate.

This is pretty handy, especially for linter errors related to formatting (in that case, you don't have any manual update to perform)

Run locally

MegaLinter can be run locally thanks to mega-linter-runner.

Reports

Capabilities

Accuracy: Count the total number of errors, not only the number of files in error.
Show linter version and applied filters for each linter processed.
Reports stored as artifacts on GitHub Actions runs or other remote files
- General log
- One report file by linter

Additional Reporters

Console

Gitlab Merge Request comments

Bitbucket Pull Request comments

Azure Pull Request comments

Markdown Summary

Enhanced configuration

Assisted installation and configuration using a Yeoman generator and JSON schemas for the configuration file

Configure include and exclude regexes for a single language or linter: e.g., JAVASCRIPT_FILTER_REGEX_INCLUDE (src)
Configure additional CLI arguments for a linter: e.g., JAVASCRIPT_ES_ARGUMENTS "--debug --env-info"
Configure non-blocking errors for a single language or linter: e.g., JAVASCRIPT_DISABLE_ERRORS
Simplified languages and linters variables
- ENABLE = list of languages and formats to apply lint on codebase (default: all)
- ENABLE_LINTERS = list of linters to apply lint on codebase (default: all)
- DISABLE = list of languages and formats to skip (default: none)
- DISABLE_LINTERS = list of linters to skip (default: none)
- Variables VALIDATE_XXX are still taken in account (but should not be used in association with ENABLE and DISABLE variables)

Enhanced documentation

HTML documentation

One page per linter documentation:
- All variables that can be used with this linter
- List of file extensions, names and filters applied by the linter
- Link to MegaLinter default linter configuration
- Link to linter website
- Link to official page explaining how to customize the linter rules
- Link to official page explaining how to disable rules from source comments
- Examples of linter command line calls behind the hood
- Help command text
- Installation commands

Installation links for related IDEs

README
- Separate languages, formats, and tooling formats in the linters table
- Add logos for each descriptor

Plugin management

For less commonly used linters, MegaLinter offers a plugin architecture so anyone can publish plugins.

Simplify architecture and evolutionary maintenance

Refactoring runtime in Python, for easier handling than Bash thanks to classes and Python modules
Everything related to each linter is in a single descriptor YAML file
- Easier ongoing maintenance
- Fewer conflicts to manage between PRs
- A few special cases require a Python linter class)
Default behaviors for all linters, with the possibility to override parts of them for special cases
Hierarchical architecture: Apply fixes and new behaviors to all linters with a single code update
Documentation as code
- Generate linters tables (ordered by type: language, format, and tooling format) and include them in the README. (see result)
- Generate one markdown file per linter, containing all configuration variables, information, and examples (see examples)
Automatic generation of Dockerfiles using YAML descriptors, always using the linter's latest version
- Dockerfile commands (FROM, ARG, ENV, COPY, RUN)
- APK packages (Linux)
- NPM packages (Node.js)
- PIP packages (Python)
- GEM packages (Ruby)
- Phive packages (PHP)
Have a centralized exclude list (node_modules, .rbenv, etc.)

Improve robustness & stability

Test classes for each capability
Test classes for each linter: automatic generation of test classes using .automation/build.py
Set up code coverage
Development CI/CD
- Validate multi-status on PR inside each PR (posted from step "Run against all code base")
- Run test classes and code coverage with pytest during validation GitHub Action
- Validate descriptor YML files with json schema during build
- Automated job to upgrade linters to their latest stable version

microsoft/vscode-remote-release

Visual Studio Code Remote Development: Open any folder in WSL, in a Docker container, or on a remote machine using SSH and take advantage of VS Code's full feature set.

Visual Studio Code Remote Development

Visual Studio Code Remote Development
Open any folder in a container, on a remote machine, or in WSL and take advantage of VS Code's full feature set. Learn more!

This repository is for providing feedback on the Visual Studio Remote Development extension pack and its related extensions. You can use the repository to report issues or submit feature requests on any of these extensions:

Remote - SSH
- Remote - SSH: Editing Configuration Files
Dev Containers
WSL
Remote - Tunnels and the Visual Studio Code Server.

If you are running into an issue with another extension you'd like to use with the Remote Development extensions, please raise an issue in the extension's repository. You can reference our summary of tips for remote related issues and our extension guide to help the extension author get started.

Issues related to the Dev Container ecosystem may be reported in several places. Issues involving Features, Templates, or Images can be reported in the relevant repo. Issues relating to the open source dev container CLI can be reported on devcontainers/cli. You may use the dev container spec repository to file and review issues to shape the direction of development containers and the dev container CLI.

Documentation

Running into trouble? Wondering what you can do? These articles can help.

Releases

VS Code Remote Development extension "stable" releases are tied directly to VS Code releases. Release highlights can be found in VS Code release notes which will include a link to detailed extension release notes.

The extensions are developed using the same development process and schedule as VS Code itself. You can see what is planned for the current development iteration in a pinned planning issue in this repository. This issue will include a link to the broader VS Code plan. As with VS Code itself, the extensions will update during a development iteration with changes that are only available in VS Code Insiders Edition.

Providing Feedback

You can use this repository to:

Up-vote a feature or request a new one.
Search for existing issues already reported for potential workarounds.
Report a problem if you don't find what you are looking for.

If you have a question, connect with the community using any of these social platforms:

See our CONTRIBUTING guide for more details.

License

By downloading and using the Visual Studio Remote Development extension pack and its related extensions, you agree to the product license terms and privacy statement.

License for this repository:

Copyright © Microsoft Corporation All rights reserved.
Creative Commons Attribution 4.0 License (International): https://creativecommons.org/licenses/by/4.0/legalcode

TechHutTV/homelab

Homelab stacks, templates, and more fun resources!

My Homelab Setup

This repo contains Docker Compose stacks, configuration templates, and documentation for everything running in my homelab. It spans two servers - an Unraid NAS for media and a Proxmox node for everything else - tied together with Ubiquiti networking, self-hosted cloud services, and a full monitoring stack.

Whether you're looking for a complete Servarr media setup behind a VPN, a Frigate NVR config with Coral TPU, or just want to see how someone else organizes their self-hosted infrastructure, feel free to dig around and use whatever is helpful. This is a work in progress - I still have a ton to update and add.

Apps - List of all the apps and services.
Automations - n8n workflows and automation.
Cloud - NextCloud, Immich, and self-hosted cloud services.
Home Assistant - Smart home services and automation.
Media Server - Plex, Jellyfin, *arr stack, and more.
Monitoring - Graphs and visualizations for Unraid, Proxmox, and more.
NetBird - Self-hosted zero-trust networking with PocketID.
Proxy Management - NGINX Proxy Manager, DDNS with Cloudflare, local domains, and more.
Storage - Current storage and backup solution.
Surveillance - Frigate NVR solution with Coral TPU.

Hardware

Compute

	OpnNAS SL-R12 Pro	Miniforum AI X1 Pro
OS	Unraid	Proxmox
Role	Media server, NextCloud VM	Grafana, NPM, n8n, and other services
CPU	Intel Core i5-13500T	AMD Ryzen AI 9 HX 370
RAM	Crucial Pro 96GB DDR5	96GB SODIMM DDR5
Storage	5x Seagate Exos 20TB, 7x Seagate IronWolf 4TB	2x WD SN580 1TB NVMe (mirrored boot)
Link	learn more	get it here

The OpnNAS is an early release press model - check their site for availability. The Miniforum handles all non-media workloads as a dedicated Proxmox node.

Networking

Ubiquiti sent all of this over to me. There is no way I'd be able to afford all this stuff on my own dime, so note that. This setup is crazy overpowered for what I need.

Device	Description
UDM Pro Max	Primary router, gateway, and UniFi Protect NVR with 2x 8TB HDDs for camera storage.
USW Pro Max 24 PoE	Main 24-port PoE switch powering cameras and access points.
USW Pro XG 10 PoE	10G aggregation switch for high-bandwidth connections between devices.
2x U7 Pro XG	Wi-Fi 7 access points providing wireless coverage.
USW Lite 16 PoE	Secondary 16-port PoE switch for additional wired devices.

Accessories

1x U-Rack-6U-TL
1x UACC-Cable-Patch-EL-0.15M-W-24
5x UACC-Cable-Patch-EL-3M-W
2x UACC-Cable-Patch-EL-15M-W

Security

Currently running two camera systems - originally fully Reolink, but added UniFi Protect after Ubiquiti sent equipment to try. See the video overview.

Camera	Details
3x UVC-G6-Turret-W	Connected to the UDM Pro Max via UniFi Protect. Planning to slowly transition fully to Ubiquiti as budget allows.
Reolink PoE	RLC-1224A 12MP and 4K Floodlight. Great for the Reolink ecosystem and 3rd party services like Frigate.
Reolink NVR Kit	16CH 12MP (my kit) - simple PoE plug-and-play solution. Kit cameras require the NVR to function. Budget option: 8CH 5MP.

Other Devices

Raspberry Pi 5 (PoE HAT) - Twingate connector and Cloudflare DDNS updater.
Raspberry Pi 4 - OctoPrint for 3D printer management.
VPS (Hostinger KVM) - Self-hosted NetBird management server.

Previous hardware? See old_hardware.md.

Stars

redhat-openshift-ecosystem/certified-operators

Production catalog for Red Hat Certified Operator Bundles

Red Hat certified operators production catalog

Production catalog for Red Hat Certified Operator Bundles

See our documentation to find out more about Certified operators and contribution.

Operator bundle submission

A new operator bundle submission needs to follow a predefined directory structure that is described below in this section. The new submission is done through Github pull requests which can be either open by the CI pipeline or manually by a user. The recommended way is to use the CI pipeline because it makes sure all necessary data are provided in the correct format. Documentation about how to use the pipeline is available in the pipeline repository.

Pull request

A pull request with a new operator bundle needs to follow given rules to pass a tests:

Title format: operator package-name (version)
Pull request can only modify one operator
Pull request can't modify already merged operators
Associated images need to be pinned to specific image digest - tags are not allowed

Rules mentioned above are always followed when pull request is opened using CI pipeline.

Directory structure

This repository contains an operator directory where all certified operators are stored. Each operator has its directory with its package name. Inside the directory, you have to provide a ci.yaml file that stores the necessary metadata for a successful certification process. The format of the file is described below.

operators
└── kogito-operator
    ├── 1.6.0
    │   ├── manifests
    │   │   ├── app.kiegroup.org_kogitobuilds.yaml
    │   │   ├── app.kiegroup.org_kogitoinfras.yaml
    │   │   ├── app.kiegroup.org_kogitoruntimes.yaml
    │   │   ├── app.kiegroup.org_kogitosupportingservices.yaml
    │   │   ├── kogito-operator.clusterserviceversion.yaml
    │   │   └── kogito-operator-controller-manager_v1_serviceaccount.yaml
    │   └── metadata
    │       └── annotations.yaml
    └── ci.yaml

Format of ci.yaml file

In the file, user needs to provide necessary details for the operator certification process. Currently, the certification process supports the following options:

cert_project_id - Identifier of certification project created through Red Hat Connect.
merge - A boolean value that determines whether a new operator is automatically merged when passed all required checks. (optional, default: True)

AsahiLinux/docs

Asahi Linux documentation

Asahi Linux documentation repository

This is the Asahi Linux documentation repository.

Documentation structure

Our documentation is organised into categories.

alt: Alternative operating system/Linux distribution support documentation should go here.
fw: Documentation on vendor-controlled firmware and firmware interfaces should go here.
hw: Any documentation related to hardware belongs here. This is further split into subcategories:
- cpu: Application processor documentation
- devices: Documentation relating to specific Mac models
- peripherals: hardware found in Apple Silicon Macs but not the SoC itself
- soc: hardware blocks integrated into Apple Silicon SoCs
platform: Documentation that applies across the Apple Silicon platform
project: Project admin documents and stuff unrelated to hardware or software
sw: Documentation for non-firmware software

Usage

This is made with MkDocs. If you have mkdocs installed already, run make build to build the site, or make test to spin up a local webserver for review. If you don't, feel free to use our container with something like:

$ podman run -it --pull=newer -p=8000:8000 -v=$(pwd)/:/docs:z ghcr.io/asahilinux/mkdocs-asahi:latest

if you're using Podman, or

$ docker run -it --pull=always -p=8000:8000 -v=$(pwd)/:/docs:z ghcr.io/asahilinux/mkdocs-asahi:latest

if you're using Docker. Note that this repository uses Git Submodules, so you'll want to set those up first with git submodule update --init.

The website is rebuilt by the CI on every commit and served via GitHub Pages. The container is also automatically updated and pushed to the registry.

autowarefoundation/autoware

Autoware - the world's leading open-source software project for autonomous driving

Autoware is an open-source software stack for self-driving vehicles, built on the Robot Operating System (ROS). It includes all of the necessary functions to drive an autonomous vehicles from localization and object detection to route planning and control, and was created with the aim of enabling as many individuals and organizations as possible to contribute to open innovations in autonomous driving technology.

Documentation

To learn more about using or developing Autoware, refer to the Autoware documentation site. You can find the source for the documentation in autowarefoundation/autoware-documentation.

Repository overview

autowarefoundation/autoware
- Meta-repository containing .repos files to construct an Autoware workspace.
- It is anticipated that this repository will be frequently forked by users, and so it contains minimal information to avoid unnecessary differences.
autowarefoundation/autoware_core
- Main repository for high-quality, stable ROS packages for Autonomous Driving.
- Based on Autoware.Auto and Autoware.Universe.
autowarefoundation/autoware_universe
- Repository for experimental, cutting-edge ROS packages for Autonomous Driving.
- Autoware Universe was created to make it easier for researchers and developers to extend the functionality of Autoware Core
autowarefoundation/autoware_launch
- Launch configuration repository containing node configurations and their parameters.
autowarefoundation/autoware-github-actions
- Contains reusable GitHub Actions workflows used by multiple repositories for CI.
- Utilizes the DRY concept.
autowarefoundation/autoware-documentation
- Documentation repository for Autoware users and developers.
- Since Autoware Core/Universe has multiple repositories, a central documentation repository is important to make information accessible from a single place.

Using Autoware.AI

If you wish to use Autoware.AI, the previous version of Autoware based on ROS 1, switch to autoware-ai repository. However, be aware that Autoware.AI has reached the end-of-life as of 2022, and we strongly recommend transitioning to Autoware Core/Universe for future use.

Contributing

There is no formal process to become a contributor - you can comment on any existing issues or make a pull request on any Autoware repository!
- Make sure to follow the Contribution Guidelines.
- Take a look at Autoware's various working groups to gain an understanding of any work in progress and to see how projects are managed.
If you have any technical questions, you can start a discussion in the Q&A category to request help and confirm if a potential issue is a bug or not.

Useful resources

linuxserver/docker-unifi-network-application

The LinuxServer.io team brings you another container release featuring:

regular and timely application updates
easy user mappings (PGID, PUID)
custom base image with s6 overlay
weekly base OS updates with common layers across the entire LinuxServer.io ecosystem to minimise space usage, down time and bandwidth
regular security updates

Find us at:

Blog - all the things you can do with our containers including How-To guides, opinions and much more!
Discord - realtime support / chat with the community and the team.
Discourse - post on our community forum.
GitHub - view the source for all of our repositories.
Open Collective - please consider helping us by either donating or contributing to our budget

linuxserver/unifi-network-application

The Unifi-network-application software is a powerful, enterprise wireless software engine ideal for high-density client deployments requiring low latency and high uptime performance.

Supported Architectures

We utilise the docker manifest for multi-platform awareness. More information is available from docker here and our announcement here.

Simply pulling lscr.io/linuxserver/unifi-network-application:latest should retrieve the correct image for your arch, but you can also pull specific arch images via tags.

The architectures supported by this image are:

Architecture	Available	Tag
x86-64	✅	amd64-<version tag>
arm64	✅	arm64v8-<version tag>

Application Setup

After setup, the web UI is available at https://ip:8443. The application can be configured, or a backup restored, using the first run wizard.

This container requires an external mongodb database instance.

Setting Up Your External Database

Starting with version 8.1 of Unifi Network Application, mongodb 3.6 through 7.0 are supported. Starting with version 9.0 of Unifi Network Application, mongodb 8.0 is also supported.

Make sure you pin your database image version and do not use latest, as mongodb does not support automatic upgrades between major versions.

MongoDB >4.4 on X86_64 Hardware needs a CPU with AVX support. Some lower end Intel CPU models like Celeron and Pentium (before Tiger-Lake) more Details: Advanced Vector Extensions - Wikipedia don't support AVX, but you can still use MongoDB 4.4.

If you are using the official mongodb container, you can create your user using an init-mongo.sh file with the following contents (do not modify; copy/paste as is):

#!/bin/bash

if which mongosh > /dev/null 2>&1; then
  mongo_init_bin='mongosh'
else
  mongo_init_bin='mongo'
fi
"${mongo_init_bin}" <<EOF
use ${MONGO_AUTHSOURCE}
db.auth("${MONGO_INITDB_ROOT_USERNAME}", "${MONGO_INITDB_ROOT_PASSWORD}")
db.createUser({
  user: "${MONGO_USER}",
  pwd: "${MONGO_PASS}",
  roles: [
    { db: "${MONGO_DBNAME}", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_stat", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_audit", role: "dbOwner" }
  ]
})
EOF

Mount the sh file into your mongodb container, and make sure to set the env vars below with the same values you supplied to the Unifi container.

For example:

  unifi-db:
    image: docker.io/mongo:<version tag>
    container_name: unifi-db
    environment:
      - MONGO_INITDB_ROOT_USERNAME=root
      - MONGO_INITDB_ROOT_PASSWORD=
      - MONGO_USER=unifi
      - MONGO_PASS=
      - MONGO_DBNAME=unifi
      - MONGO_AUTHSOURCE=admin
    volumes:
      - /path/to/data:/data/db
      - /path/to/init-mongo.sh:/docker-entrypoint-initdb.d/init-mongo.sh:ro
    restart: unless-stopped

Note that the init script method will only work on first run. If you start the Mongodb container without an init script it will generate test data automatically and you will have to manually create your databases, or restart with a clean /data/db volume and an init script mounted.

You can also run the commands directly against the database using either mongo (< 6.0) or mongosh (>= 6.0).

Device Adoption

For Unifi to adopt other devices, e.g. an Access Point, it is required to change the inform IP address. Because Unifi runs inside Docker by default it uses an IP address not accessible by other devices. To change this go to Settings > System > Advanced and set the Inform Host to a hostname or IP address accessible by your devices. Additionally the checkbox "Override" has to be checked, so that devices can connect to the controller during adoption (devices use the inform-endpoint during adoption).

Note that you must use 8080:8080. If you MUST change the port, it must be changed on both sides and manually changed in your system.properties file. Otherwise, devices will initially communicate and then break after.

Please note, Unifi change the location of this option every few releases so if it's not where it says, search for "Inform" or "Inform Host" in the settings.

In order to manually adopt a device take these steps:

ssh ubnt@$AP-IP
set-inform http://$address:8080/inform

The default device password is ubnt. $address is the IP address of the host you are running this container on and $AP-IP is the Access Point IP address.

When using a Security Gateway (router) it could be that network connected devices are unable to obtain an ip address. This can be fixed by setting "DHCP Gateway IP", under Settings > Networks > network_name, to a correct (and accessible) ip address.

Migration From Unifi-Controller

If you were using the mongoless tag for the Unifi Controller container, you can switch directly to the Unifi Network Application container without needing to perform any migration steps.

You cannot perform an in-place upgrade from an existing Unifi-Controller container, you must run a backup and then a restore.

The simplest migration approach is to take a full backup of your existing install, including history, from the Unifi-Controller web UI, then shut down the old container.

You can then start up the new container with a clean /config mount (and a database container configured), and perform a restore using the setup wizard.

Strict reverse proxies

This image uses a self-signed certificate by default. This naturally means the scheme is https. If you are using a reverse proxy which validates certificates, you need to disable this check for the container.

Usage

To help you get started creating a container from this image you can either use docker-compose or the docker cli.

[!NOTE] Unless a parameter is flagged as 'optional', it is mandatory and a value must be provided.

docker-compose (recommended, click here for more info)

---
services:
  unifi-network-application:
    image: lscr.io/linuxserver/unifi-network-application:latest
    container_name: unifi-network-application
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - MONGO_USER=unifi
      - MONGO_PASS=
      - MONGO_HOST=unifi-db
      - MONGO_PORT=27017
      - MONGO_DBNAME=unifi
      - MONGO_AUTHSOURCE=admin
      - MEM_LIMIT=1024 #optional
      - MEM_STARTUP=1024 #optional
      - MONGO_TLS= #optional
    volumes:
      - /path/to/unifi-network-application/data:/config
    ports:
      - 8443:8443
      - 3478:3478/udp
      - 10001:10001/udp
      - 8080:8080
      - 1900:1900/udp #optional
      - 8843:8843 #optional
      - 8880:8880 #optional
      - 6789:6789 #optional
      - 5514:5514/udp #optional
    restart: unless-stopped

docker cli (click here for more info)

docker run -d \
  --name=unifi-network-application \
  -e PUID=1000 \
  -e PGID=1000 \
  -e TZ=Etc/UTC \
  -e MONGO_USER=unifi \
  -e MONGO_PASS= \
  -e MONGO_HOST=unifi-db \
  -e MONGO_PORT=27017 \
  -e MONGO_DBNAME=unifi \
  -e MONGO_AUTHSOURCE=admin \
  -e MEM_LIMIT=1024 `#optional` \
  -e MEM_STARTUP=1024 `#optional` \
  -e MONGO_TLS= `#optional` \
  -p 8443:8443 \
  -p 3478:3478/udp \
  -p 10001:10001/udp \
  -p 8080:8080 \
  -p 1900:1900/udp `#optional` \
  -p 8843:8843 `#optional` \
  -p 8880:8880 `#optional` \
  -p 6789:6789 `#optional` \
  -p 5514:5514/udp `#optional` \
  -v /path/to/unifi-network-application/data:/config \
  --restart unless-stopped \
  lscr.io/linuxserver/unifi-network-application:latest

Parameters

Containers are configured using parameters passed at runtime (such as those above). These parameters are separated by a colon and indicate <external>:<internal> respectively. For example, -p 8080:80 would expose port 80 from inside the container to be accessible from the host's IP on port 8080 outside the container.

Parameter	Function
`-p 8443:8443`	Unifi web admin port
`-p 3478:3478/udp`	Unifi STUN port
`-p 10001:10001/udp`	Required for AP discovery
`-p 8080:8080`	Required for device communication
`-p 1900/udp`	Required for `Make controller discoverable on L2 network` option
`-p 8843`	Unifi guest portal HTTPS redirect port
`-p 8880`	Unifi guest portal HTTP redirect port
`-p 6789`	For mobile throughput test
`-p 5514/udp`	Remote syslog port
`-e PUID=1000`	for UserID - see below for explanation
`-e PGID=1000`	for GroupID - see below for explanation
`-e TZ=Etc/UTC`	specify a timezone to use, see this list.
`-e MONGO_USER=unifi`	Mongodb Username. Only evaluated on first run. Special characters must be url encoded.
`-e MONGO_PASS=`	Mongodb Password. Only evaluated on first run. Special characters must be url encoded.
`-e MONGO_HOST=unifi-db`	Mongodb Hostname. Only evaluated on first run.
`-e MONGO_PORT=27017`	Mongodb Port. Only evaluated on first run.
`-e MONGO_DBNAME=unifi`	Mongodb Database Name (stats DB is automatically suffixed with `_stat`). Only evaluated on first run.
`-e MONGO_AUTHSOURCE=admin`	Mongodb authSource. For Atlas set to `admin`. Only evaluated on first run.
`-e MEM_LIMIT=1024`	Optionally change the Java memory limit (in Megabytes). Set to `default` to reset to default
`-e MEM_STARTUP=1024`	Optionally change the Java initial/minimum memory (in Megabytes). Set to `default` to reset to default
`-e MONGO_TLS=`	Mongodb enable TLS. Only evaluated on first run.
`-v /config`	Persistent config files

Environment variables from files (Docker secrets)

You can set any environment variable from a file by using a special prepend FILE__.

As an example:

-e FILE__MYVAR=/run/secrets/mysecretvariable

Will set the environment variable MYVAR based on the contents of the /run/secrets/mysecretvariable file.

Umask for running applications

For all of our images we provide the ability to override the default umask settings for services started within the containers using the optional -e UMASK=022 setting. Keep in mind umask is not chmod it subtracts from permissions based on it's value it does not add. Please read up here before asking for support.

User / Group Identifiers

When using volumes (-v flags), permissions issues can arise between the host OS and the container, we avoid this issue by allowing you to specify the user PUID and group PGID.

Ensure any volume directories on the host are owned by the same user you specify and any permissions issues will vanish like magic.

In this instance PUID=1000 and PGID=1000, to find yours use id your_user as below:

id your_user

Example output:

uid=1000(your_user) gid=1000(your_user) groups=1000(your_user)

Docker Mods

We publish various Docker Mods to enable additional functionality within the containers. The list of Mods available for this image (if any) as well as universal mods that can be applied to any one of our images can be accessed via the dynamic badges above.

Support Info

Shell access whilst the container is running:

docker exec -it unifi-network-application /bin/bash

To monitor the logs of the container in realtime:
```
docker logs -f unifi-network-application
```

Container version number:

docker inspect -f '{{ index .Config.Labels "build_version" }}' unifi-network-application

Image version number:

docker inspect -f '{{ index .Config.Labels "build_version" }}' lscr.io/linuxserver/unifi-network-application:latest

Updating Info

Most of our images are static, versioned, and require an image update and container recreation to update the app inside. With some exceptions (noted in the relevant readme.md), we do not recommend or support updating apps inside the container. Please consult the Application Setup section above to see if it is recommended for the image.

Below are the instructions for updating containers:

Via Docker Compose

Update images:

All images:
```
docker-compose pull
```

Single image:

docker-compose pull unifi-network-application

Update containers:

All containers:
```
docker-compose up -d
```

Single container:

docker-compose up -d unifi-network-application

You can also remove the old dangling images:
```
docker image prune
```

Via Docker Run

Update the image:

docker pull lscr.io/linuxserver/unifi-network-application:latest

Stop the running container:
```
docker stop unifi-network-application
```
Delete the container:
```
docker rm unifi-network-application
```
Recreate a new container with the same docker run parameters as instructed above (if mapped correctly to a host folder, your /config folder and settings will be preserved)
You can also remove the old dangling images:
```
docker image prune
```

Image Update Notifications - Diun (Docker Image Update Notifier)

[!TIP] We recommend Diun for update notifications. Other tools that automatically update containers unattended are not recommended or supported.

Building locally

If you want to make local modifications to these images for development purposes or just to customize the logic:

git clone https://github.com/linuxserver/docker-unifi-network-application.git
cd docker-unifi-network-application
docker build \
  --no-cache \
  --pull \
  -t lscr.io/linuxserver/unifi-network-application:latest .

The ARM variants can be built on x86_64 hardware and vice versa using lscr.io/linuxserver/qemu-static

docker run --rm --privileged lscr.io/linuxserver/qemu-static --reset

Once registered you can define the dockerfile to use with -f Dockerfile.aarch64.

Versions

20.10.25: - Switch to using FW API endpoint for version checks.
08.05.25: - Update sample init-mongo.sh for compatibility with 9.1.120 (only affects new installs).
13.02.25: - Revert JRE to 17.
12.02.25: - Bump JRE to 21.
11.08.24: - Important: The mongodb init instructions have been updated to enable auth (RBAC). We have been notified that if RBAC is not enabled, the official mongodb container allows remote access to the db contents over port 27017 without credentials. If you set up the mongodb container with the old instructions we provided, you should not map or expose port 27017. If you would like to enable auth, the easiest way is to create new instances of both unifi and mongodb with the new instructions and restore unifi from a backup.
11.08.24: - Rebase to Ubuntu Noble.
04.03.24: - Install from zip package instead of deb.
17.10.23: - Add environment variables for TLS and authSource to support Atlas and new MongoDB versions.
05.09.23: - Initial release.

yankils/Simple-DevOps-Project

Simple DevOps Project

This Repository is a collection of Implementation documents.

Purpose:

By following this repository you can able to setup a DevOps CI/CD Pipeline using

git
Jenkins
Maven
Ansible
Docker &
Kubernetes

github-samples/planventure

Planventure is a sample app used in GitHub for Beginners

Getting Started 👩🏽‍💻

Fork this repository to your GitHub account.
Switch to the api-start branch.
Clone the repository to your local machine.

You can find next steps in the README on the api-start branch.

Build with Me + GitHub Copilot 🚀

You can build along with me in this Youtube video or read this blog post.

Planventure API 🚁

A Flask-based REST API backend for the Planventure application.

Prerequisites

Before you begin, ensure you have the following:

A GitHub account - sign up for FREE
Access to GitHub Copilot - sign up for FREE!
A Code Editor - VS Code is recommended
API Client (like Bruno)
Git - Download & Install Git

Happy Coding! 🎉

dunglas/symfony-docker

A Docker-based installer and runtime for Symfony. Install: download and `docker compose up`.

Symfony Docker

A Docker-based installer and runtime for the Symfony web framework, with FrankenPHP and Caddy inside!

Getting Started

If not already done, install Docker Compose (v2.10+)
Run docker compose build --pull --no-cache to build fresh images
Run docker compose up --wait to set up and start a fresh Symfony project
Open https://localhost in your favorite web browser and accept the auto-generated TLS certificate
Run docker compose down --remove-orphans to stop the Docker containers.

Features

Production, development and CI ready
Just 1 service by default
Blazing-fast performance thanks to the worker mode of FrankenPHP
Installation of extra Docker Compose services with Symfony Flex
Automatic HTTPS (in dev and prod)
HTTP/3 and Early Hints support
Real-time messaging thanks to a built-in Mercure hub
Vulcain support
Native XDebug integration
Super-readable configuration
Rootless, slim production image

Enjoy!

Docs

License

Symfony Docker is available under the MIT License.

Credits

Created by Kévin Dunglas, co-maintained by Maxime Helias and sponsored by Les-Tilleuls.coop.

Anduin2017/HowToCook

程序员在家做饭方法指南。Programmer's guide about how to cook at home (Simplified Chinese only).

程序员做饭指南

最近宅在家做饭，作为程序员，我偶尔在网上找找菜谱和做法。但是这些菜谱往往写法千奇百怪，经常中间莫名出来一些材料。对于习惯了形式语言的程序员来说极其不友好。

所以，我计划自己搜寻菜谱并结合实际做菜的经验，准备用更清晰精准的描述来整理常见菜的做法，以方便程序员在家做饭。

同样，我希望它是一个由社区驱动和维护的开源项目，使更多人能够一起做一个有趣的仓库。所以非常欢迎大家贡献它~

本地部署

如果需要在本地部署菜谱 Web 服务，可以在安装 Docker 后运行下面命令：

docker pull ghcr.io/anduin2017/how-to-cook:latest
docker run -d -p 5000:80 ghcr.io/anduin2017/how-to-cook:latest

如需下载 PDF 版本，可以在浏览器中访问 /document.pdf

如何贡献

针对发现的问题，直接修改并提交 Pull request 即可。

在写新菜谱时，请复制并修改已有的菜谱模板: 示例菜。

搭建环境

菜谱

按难度索引

素菜

荤菜

水产

早餐

主食

半成品加工

汤与粥

饮料

酱料和其它材料

甜品

进阶知识学习

如果你已经做了许多上面的菜，对于厨艺已经入门，并且想学习更加高深的烹饪技巧，请继续阅读下面的内容：

衍生作品推荐

nodejs/docker-node

Official Docker Image for Node.js 🐳 🐢 🚀

Node.js

node - Docker Official Images on Docker Hub

The official Node.js docker image, made with love by the node community.

What is Node.js?

Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

See: https://nodejs.org

How to use this image

Create a `Dockerfile` in your Node.js app project

# specify the node base image with your desired version node:<version>
FROM node:24
# replace this with your application's default port
EXPOSE 8888

You can then build and run the Docker image:

$ docker build -t my-nodejs-app .
$ docker run -it --rm --name my-running-app my-nodejs-app

If you prefer Docker Compose:

services:
  node:
    image: "node:24"
    user: "node"
    working_dir: /home/node/app
    environment:
      - NODE_ENV=production
    volumes:
      - ./:/home/node/app
    ports: # use if it is necessary to expose the container to the host machine
      - "8888:8888"
    command: ["npm", "start"]

You can then run using Docker Compose:

$ docker-compose up -d

Docker Compose example mounts your current directory (including node_modules) to the container. It assumes that your application has a file named package.json defining start script.

Best Practices

We have assembled a Best Practices Guide for those using these images on a daily basis.

Run a single Node.js script

For many simple, single file projects, you may find it inconvenient to write a complete Dockerfile. In such cases, you can run a Node.js script by using the Node.js Docker image directly:

$ docker run -it --rm --name my-running-script -v "$PWD":/usr/src/app -w /usr/src/app node:24 node your-daemon-or-script.js

Verbosity

Prior to 8.7.0 and 6.11.4, the docker images overrode the default npm log level from warn to info. However, due to improvements to npm and new Docker patterns (e.g. multi-stage builds) the working group reached a consensus to revert the log level to npm defaults. If you need more verbose output, please use one of the following methods to change the verbosity level.

Dockerfile

If you create your own Dockerfile which inherits from the node image, you can simply use ENV to override NPM_CONFIG_LOGLEVEL.

FROM node
ENV NPM_CONFIG_LOGLEVEL=info
...

Docker Run

If you run the node image using docker run, you can use the -e flag to override NPM_CONFIG_LOGLEVEL.

$ docker run -e NPM_CONFIG_LOGLEVEL=info node ...

npm run

If you are running npm commands, you can use --loglevel to control the verbosity of the output.

$ docker run node npm --loglevel=warn ...

Image Variants

The node images come in many flavors, each designed for a specific use case. All of the images contain pre-installed versions of node, npm, and Yarn v1 Classic. For each supported architecture, the supported variants are different. In the file: versions.json, it lists all supported variants for all of the architectures that we support now. See Yarn v1 Classic bundling for future plans to remove this legacy version.

`node:<version>`

This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of. This tag is based off of buildpack-deps. buildpack-deps is designed for the average user of docker who has many images on their system. It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system.

`node:alpine`

This image is based on the popular Alpine Linux project, available in the alpine official image. Alpine Linux is much smaller than most distribution base images (~5MB), and thus leads to much slimmer images in general.

This variant is highly recommended when final image size being as small as possible is desired. The main caveat to note is that it does use musl libc instead of glibc and friends, so certain software might run into issues depending on the depth of their libc requirements. However, most software doesn't have an issue with this, so this variant is usually a very safe choice. See this Hacker News comment thread for more discussion of the issues that might arise and some pro/con comparisons of using Alpine-based images.

One common issue that may arise is a missing shared library required for use of process.dlopen. To add the missing shared libraries to your image:

For Alpine v3.18 and earlier, adding the libc6-compat package in your Dockerfile is recommended: apk add --no-cache libc6-compat
Starting from Alpine v3.19, you can use the gcompat package to add the missing shared libraries: apk add --no-cache gcompat

To minimize image size, it's uncommon for additional related tools (such as git or bash) to be included in Alpine-based images. Using this image as a base, add the things you need in your own Dockerfile (see the alpine image description for examples of how to install packages if you are unfamiliar).

To make the image size even smaller, you can bundle without npm/yarn.

`node:bullseye`

This image is based on version 11 of Debian, available in the debian official image.

`node:bookworm`

This image is based on version 12 of Debian, available in the debian official image.

`node:trixie`

This image is based on version 13 of Debian, available in the debian official image.

`node:slim`

This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run node. Unless you are working in an environment where only the Node.js image will be deployed and you have space constraints, we highly recommend using the default image of this repository.

License

License information for the software contained in this image. License information for the Node.js Docker project.

Supported Docker versions

If you are using Docker Desktop, it is recommended to use a recent version, released in the last six months.

Refer to Docker Engine release notes for current Engine versions.

Supported Node.js versions

This project will support Node.js versions as still under active support as per the Node.js release schedule.

Yarn v1 Classic bundling

Yarn v1 Classic is currently bundled in node image variants. Because Yarn v1 is frozen and no longer maintained, bundling plans have been revised.

As of Node.js 26.0.0 it is planned to no longer bundle Yarn v1 into node images. For lower versions of Node.js (<26) node images will continue to bundle Yarn v1.

Users with legacy requirements for Yarn v1 under Node.js 26 and above may be able to follow Yarn v1 installation instructions and install using npm install --global yarn.

Governance and Current Members

The Node.js Docker Image is governed by an open maintainer model. See GOVERNANCE.md for project roles and decision-making, and CONTRIBUTING.md for contribution guidance. If a final decision cannot be reached using consensus seeking, the Node.js TSC is the final arbiter.

Docker Maintainers

Laurent Goderre (LaurentGoderre)
Simen Bekkhus (SimenB)
Peter Dave Hello (PeterDaveHello)
Rafael Gonzaga (rafaelgss)
Matteo Collina (mcollina)

Collaborators

Additional collaborators are managed via the @nodejs/docker team.

Emeritus

Former Maintainers

Mikeal Rogers (mikeal)
Christopher Horrell (chorrell)
Peter Petrov (pesho)
John Mitchell (jlmitch5)

sytone/obsidian-remote

Run Obsidian.md in a browser via a docker container.

obsidian-remote

This docker image allows you to run obsidian in docker as a container and access it via your web browser.

Use http://localhost:8080/ to access it locally, do not expose this to the web unless you secure it and know what you are doing!!

Using the Container

Windows based path

To run a interactive version to test it out:

docker run --rm -it `
  -v D:/ob/vaults:/vaults `
  -v D:/ob/config:/config `
  -p 8080:8080 `
  ghcr.io/sytone/obsidian-remote:latest

To run it as a daemon in the background:

docker run -d `
  -v D:/ob/vaults:/vaults `
  -v D:/ob/config:/config `
  -p 8080:8080 `
  ghcr.io/sytone/obsidian-remote:latest

The ARM container is now avaliable, will look to make this simpler in the future. The ARM imange is on the docker hub and not the github container registry.

docker run -d `
  -v D:/ob/vaults:/vaults `
  -v D:/ob/config:/config `
  -p 8080:8080 `
  sytone/obsidian-remote:arm64

Linux bash paths

To run a interactive version to test it out:

mkdir -p ob/{vaults,config}
docker run --rm -it \
  -v ./ob/vaults:/vaults \
  -v ./ob/config:/config \
  -p 8080:8080 \
  ghcr.io/sytone/obsidian-remote:latest

To run it as a daemon in the background:

mkdir -p ob/{vaults,config}
docker run -d \
  -v ./ob/vaults:/vaults \
  -v ./ob/config:/config \
  -p 8080:8080 \
  ghcr.io/sytone/obsidian-remote:latest

The ARM container is now avaliable, will look to make this simpler in the future. The ARM imange is on the docker hub and not the github container registry.

mkdir -p ob/{vaults,config}
docker run -d \
  -v ./ob/vaults:/vaults \
  -v ./ob/config:/config \
  -p 8080:8080 \
  sytone/obsidian-remote:latest

Ports

Port	Description
8080	HTTP Obsidian Web Interface
8443	HTTPS Obsidian Web Interface

Mapped Volumes

Path	Description
`/vaults`	The location on the host for your Obsidian Vaults
`/config`	The location to store Obsidan configuration and ssh data for obsidian-git

Environment Variables

Environment Variable	Description
PUID	Set the user ID for the container user. `911` by default.
PGID	Set the group ID for the continer user. `911` by default.
TZ	Set the Time Zone for the container, should match your TZ. `Etc/UTC` by default. See List of tz database time zones for valid options.
DOCKER_MODS	Use to add mods to the container like git. E.g. `DOCKER_MODS=linuxserver/mods:universal-git` See Docker Mods for details.
INSTALL_PACKAGES	Use to add package for the container like language pack. E.g. `INSTALL_PACKAGES=fonts-noto-cjk fonts-noto-extra` And the docker mod `linuxserver/mods:universal-package-install` is required.
KEYBOARD	Used to se the keyboard being used for input. E.g. `KEYBOARD=en-us-qwerty` or `KEYBOARD=de-de-qwertz` a list of other possible values (not tested) can be found at https://github.com/linuxserver/docker-digikam#keyboard-layouts
CUSTOM_PORT	Internal port the container listens on for http if it needs to be swapped from the default 8080.
CUSTOM_HTTPS_PORT	Internal port the container listens on for https if it needs to be swapped from the default 8443.
CUSTOM_USER	HTTP Basic auth username, abc is default.
PASSWORD	HTTP Basic auth password, abc is default. If unset there will be no auth
SUBFOLDER	Subfolder for the application if running a subfolder reverse proxy, need both slashes IE `/subfolder/`
TITLE	The page title displayed on the web browser, default "KasmVNC Client".
FM_HOME	This is the home directory (landing) for the file manager, default "/config".

Language Support

To show the other languages, add the mod linuxserver/mods:universal-package-install and add the language pack. E.g. INSTALL_PACKAGES=fonts-noto-cjk fonts-noto-extra to support CJK (Chinese Japanese Korean).

To type other language in the browser you should enable the IME Input Mode in the side panel.

Using Docker Compose

services:
  obsidian:
    image: 'ghcr.io/sytone/obsidian-remote:latest'
    container_name: obsidian-remote
    restart: unless-stopped
    ports:
      - 8080:8080
      - 8443:8443
    volumes:
      - /home/obsidian/vaults:/vaults
      - /home/obsidian/config:/config
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/Los_Angeles
      - DOCKER_MODS=linuxserver/mods:universal-git
      - CUSTOM_PORT="8080"
      - CUSTOM_HTTPS_PORT="8443" 
      - CUSTOM_USER=""
      - PASSWORD=""
      - SUBFOLDER=""

Enabling GIT for the obsidian-git plugin

This container uses the base images from linuxserver.io. This means you can the linuxserver.io mods. To add support for git add the DOCKER_MODS environment variable like so DOCKER_MODS=linuxserver/mods:universal-git.

Docker CLI example

docker run -d `
  -v D:/ob/vaults:/vaults `
  -v D:/ob/config:/config `
  -p 8080:8080 `
  -e DOCKER_MODS=linuxserver/mods:universal-git `
  ghcr.io/sytone/obsidian-remote:latest

Reloading Obsidan in the Browser

If you make changes to plugins or do updates that need to have obsidian restarted, instead of having to stop and start the docker container you can just close the Obsidian UI and right click to show the menus and reopen it. Here is a short clip showing how to do it.

Setting PUID and PGID

To set PUID and PGID use the follow environment variables on the command line, by default the IDs are 911/911

docker run --rm -it `
  -v D:/ob/vaults:/vaults `
  -v D:/ob/config:/config `
  -e PUID=1000 `
  -e PGID=1000 `
  -p 8080:8080 `
  ghcr.io/sytone/obsidian-remote:latest

Or, if you use docker-compose, add them to the environment: section:

environment:
  - PUID=1000
  - PGID=1000

It is most likely that you will use the id of yourself, which can be obtained by running the command below. The two values you will be interested in are the uid and gid.

id $user

Adding missing fonts

Thanks to @aaron-jang for this example.

Download the font of the language that you want to use in Obsidian and add it to the volume as shown below.

Map font file using Docker CLI

  -v {downloaded font directory}:/usr/share/fonts/truetype/{font name}

Map font file using Docker Compose

    volumes:
      - {downloaded font directory}:/usr/share/fonts/truetype/{font name}

Hosting behind a reverse proxy

If you wish to do that please make sure you are securing it in some way!. You also need to ensure websocket support is enabled.

Example nginx configuration

This is an example, I recommend a SSL based proxy and some sort of authentication.

server {
  set $forward_scheme http;
  set $server         "10.10.10.10";
  set $port           8080;

  listen 80;
  server_name ob.mycooldomain.com;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection $http_connection;
  proxy_http_version 1.1;
  access_log /data/logs/ob_access.log proxy;
  error_log /data/logs/ob_error.log warn;
  location / {
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $http_connection;
    proxy_http_version 1.1;
    # Proxy!
    add_header       X-Served-By $host;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Scheme $scheme;
    proxy_set_header X-Forwarded-Proto  $scheme;
    proxy_set_header X-Forwarded-For    $remote_addr;
    proxy_set_header X-Real-IP          $remote_addr;
    proxy_pass       $forward_scheme://$server:$port$request_uri;
  }
}

Hosting behind Nginx Proxy Manager (NPM)

Thanks to @fahrenhe1t for this example.

If you install obsidian-remote in Docker, you can proxy it through Nginx Proxy Manager (NPM - running on the same Docker instance), and use an access list to provide user authentication. The obsidian-remote container would have to be on the same network as Nginx Proxy Manager. If you don't expose the IP external to the container, authentication would be forced through NPM:

services:
  obsidian:
    image: 'ghcr.io/sytone/obsidian-remote:latest'
    container_name: obsidian-remote
    restart: unless-stopped
    ports:
      - 8080 #only exposes port internally to the container
    volumes:
      - /home/obsidian/vaults:/vaults
      - /home/obsidian/config:/config
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/Los_Angeles
      - DOCKER_MODS=linuxserver/mods:universal-git
networks:
  default:
    name: <your nginx proxy manager network>
    external: true

Create a proxy host in NPM pointing to the "obsidian-remote:8080" container, choose your domain name, use a LetsEncrypt SSL certificate, enable WebSockets. This video talks about it: Nginx Proxy Manager - ACCESS LIST protection for internal services

Updating Obsidian

By default obsidian will update itself in the container. If you recreate the container you will have to do the update again. This repo will be updated periodically to keep up with the latest version of Obsidian.

Building locally

To build and use it locally run the following commands:

docker build --pull --rm `
  -f "Dockerfile" `
  -t obsidian-remote:latest `
  "."

To run the localy build image:

docker run --rm -it `
  -v D:/ob/vaults:/vaults `
  -v D:/ob/config:/config `
  -p 8080:8080 `
  obsidian-remote:latest bash

Copy/Paste From External Source

Click on the circle to the left side of your browser window. In there you will find a textbox for updating the remote clipboard or copying from it.

GitHub Dockerfile Monthly Trending

oxsecurity/megalinter

MegaLinter, by

Table of Contents

Why MegaLinter

Quick Start

Supported Linters

Languages

Formats

Tooling formats

Other

Installation

Assisted installation

Which version to use ?

GitHub Action

GitLab CI

Azure Pipelines

Single Repository

Central Repository

Pull Request Comments

Detailed Tutorial

Bitbucket Pipelines

Jenkins

Concourse

Pipeline step

Use it as a reusable task

Drone CI

(Optional) Adjusting trigger rules

Docker container

Run MegaLinter locally

Configuration

.mega-linter.yml file

Common variables

Activation and deactivation

Filter linted files

Apply fixes

Apply fixes issues

Notes

Linter specific variables

Pre-commands

Post-commands

Environment variables security

Secured env variables

Secured configuration examples

Default secured variables

Unhide variables for linters

CLI lint mode

Reporters

Flavors

Badge

Markdown

reStructuredText

Plugins

External Plugins Catalog

Use external plugins

Example

Create your own plugin

Limitations

They talk about MegaLinter

English articles

French articles

Japanese articles

Videos

Web Sites

Linters

Frequently Asked Questions

How to contribute

Special thanks

Maintainers

Contributors

Open-source teams

Super-Linter team

License

MegaLinter vs Super-Linter

Security

Performance

More languages and formats linted

Automatically apply formatting and fixes

Run locally

Reports