GitHub Dockerfile Monthly Trending

freeCodeCamp/rdb-alpha

Prerequisites

Docker Engine
VS Code and the Dev Containers extension
Git

How to Run a Project in Docker

Clone the RDB Alpha repo with git clone https://github.com/freeCodeCamp/rdb-alpha
Open a terminal, navigate to the rdb-alpha directory, and open VSCode with code .
Press Ctrl / Cmd + Shift + P and enter Dev Containers: Rebuild Container and Reopen in Container
A new VS Code window will open and begin building the Docker image. It will take several minutes to build the first time.
Once the image is finished building, press Ctrl / Cmd + Shift + P and enter CodeRoad: Start to open CodeRoad
In the CodeRoad window, click "Start New Tutorial"
Enter the URL to the tutorial.json file of the project you want to start (ex: https://raw.githubusercontent.com/freeCodeCamp/learn-bash-by-building-a-boilerplate/main/tutorial.json)
Click the "Start" button

There may be some additional troubleshooting steps to get the container running properly. They can often be solved by following the onscreen instructions, or examining any error messages in your terminal.

How to Restart or Switch Projects

Note: If you restart or switch projects you will lose your progress, along with any files or directories you created.

Press Ctrl / Cmd + Shift + P and enter Dev Containers: Rebuild Container
Wait for VS Code to reopen and reload the Docker container
Open CodeRoad, enter the URL to a tutorial.json file, and start the project as described above

`tutorial.json` File URLs for CodeRoad

kagisearch/kagi-docs

Documentation for products made by Kagi Inc

Kagi Inc. Documentation

This repository contains open-source documentation for products made by Kagi Inc.

Knowledgebase Map

This repo serves documentation for multiple products developed by Kagi.

Product	Documentation	Repo Directory
Kagi Search	https://help.kagi.com/kagi	kagi
Orion Browser	https://help.kagi.com/orion	orion

Our documentation efforts are ongoing! We welcome your feedback and contributions - read on for details!

Support

Discussions

On our discussions page, you will find several categories:

Announcements, where we will post important updates related to the documentation in this repo.
Q&A, where you can discuss and ask questions about the documentation and APIs that we offer. This is the best place to start if you're not sure of a better place!

For topics outside of the documentation & APIs, please refer to that product's official support venues, in the Community section.

Community

Each of our products has their own forum, and we encourage you to join us there. We also have a shared Discord server where you can discuss all of our products.

Discord Invite: https://kagi.com/discord

Product	Feedback & Bug Reports
Kagi Search	kagifeedback.org
Orion Browser	orionfeedback.org

Contributing

Issues

We welcome any bug reports, requests for clarification, or other inquiries via the Issues tab.

Upon opening an issue, you will be presented with a list of templates to choose from that will help you provide us with the information we need, and triage the issue with the correct labels.

A staff member will review your issue, and help investigate what the best course of action is.

Pull Requests

Thank you for taking the time to contribute!

We welcome contributions such as:

Fixes to incorrect statements or inaccuracies within the documentation.
Extending documentation with details, or clarifying complicated explanations with easier to understand wording.
Additions that fill gaps or missing pieces in the current documentation.
Fixing of spelling and grammatical errors in the documentation.
Adding new documentation when staff calls on the community to prepare new sections.

We would ask that you withhold:

Whitespace or formatting changes.
Subjective wording changes.
Modifications to the overall structure and format of the documentation.
Additions needlessly restructure current documentation.
Additions that document unreleased product functionality.

If you are not sure, please feel free to open an issue first, and we will help guide you along!

Creating a Pull Request

Create a fork of this repo
Create a branch: git checkout -b username/my-cool-change
Follow the Building instructions to compile the book you would like to change
Make your changes
Commit your changes: git -am 'Update documentation'
Push the branch to your fork: git push origin username/my-cool-change
Create a new Pull Request

A template in the pull request form will guide you in providing any additional details we need to help accept your changes.

Building

Kagi's docs generated by Vitepress.

Development on your localhost

npm install
npm run docs:dev

vulhub/vulhub

Pre-Built Vulnerable Environments Based on Docker-Compose

Vulhub is an open-source collection of pre-built, ready-to-use vulnerable Docker environments. With just one command you can launch a vulnerable environment for security research, learning, or demonstration, no prior Docker experience required.

中文版本(Chinese version)

Quick Start

Install Docker (example for Ubuntu 24.04):

# Install the latest version docker
curl -s https://get.docker.com/ | sh

# Run docker service
systemctl start docker

For other operating systems, see the Docker documentation.

Although all Vulhub environments are running based on Docker Compose, you no longer need to install docker-compose separately. Instead, you can use the built-in docker compose command to start Vulhub environments.

Download and set up Vulhub:

git clone --depth 1 https://github.com/vulhub/vulhub

Launch a vulnerable environment:

cd vulhub/langflow/CVE-2025-3248  # Example: enter a vulnerability directory
docker compose up -d

Each environment directory contains a detailed README with reproduction steps and usage instructions.

Clean up after testing:

docker compose down -v

Note

Use a VPS or VM with at least 1GB RAM for best results
The your-ip in documentation refers to your host/VPS IP, not the Docker container IP
Ensure Docker has permission to access all files in the current directory to avoid permission errors
Some environments may not support ARM architectures, see Troubleshooting for details
All environments are for testing and educational purposes only. Do not use in production!

Troubleshooting

Docker image pull fails in mainland China

Docker Hub may be inaccessible from mainland China. Use a registry mirror or run Vulhub on an overseas VPS.

Environments fail to start on Apple Silicon (M-series) Macs

Most Vulhub environments run natively on Docker Desktop for Mac with M-series chips. If an environment fails, try setting the platform explicitly:

export DOCKER_DEFAULT_PLATFORM=linux/amd64
docker compose up -d

Environments fail on Kali Linux

Some environments may fail on Kali Linux due to a low ulimit nofile setting. See the FAQ for the fix.

If you encounter issues that you cannot resolve, feel free to seek help from the community:

Contributing

We welcome contributions! Please read our Contributing Guide to get started.

Thanks to all contributors:

Partners

Our partners and users:

Sponsor Vulhub on GitHub Sponsor, OpenCollective, or Patreon 🙏

More ways to donate.

License

Vulhub is licensed under the MIT License. See LICENSE for details.

redhat-openshift-ecosystem/community-operators-prod

community-operators metadata backing OpenShift OperatorHub

Openshift Community Operators

About this repository

This repo is the canonical source for Kubernetes Operators that appear on OpenShift Container Platform and OKD.

NOTE The index catalog registry.redhat.io/redhat/community-operator-index:v<OCP Version> is built from this repository and it is consumed by Openshift and OKD to create their sources and built their catalog. To know more about how Openshift catalog are built see the documentation.

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

Add your Operator

We would love to see your Operator added to this collection. We currently use automated vetting via continuous integration plus manual review to curate a list of high-quality, well-documented Operators. If you are new to Kubernetes Operators start here.

Contributing Guide

IMPORTANT NOTICE

Some APIs versions are deprecated and are OR will no longer be served. See https://redhat-openshift-ecosystem.github.io/operator-pipelines/#important-notice

Reporting Bugs

Use the issue tracker in this repository to report bugs.

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

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)

goldbergyoni/nodebestpractices

✅ The Node.js best practices list (July 2026)

Node.js Best Practices

Follow us on Twitter! @nodepractices

Read in a different language: CN, FR, BR, RU, PL, JA, EU (ES, HE, KR and TR in progress! )

🎊 2026 edition is here!

🛰 Modernized to 2026: Tons of text edits, new recommended libraries, and some new best practices
✨ Easily focus on new content: Already visited before? Search for #new or #updated tags for new content only
🔖 Curious to see examples? We have a starter: Visit Practica.js, our application example and boilerplate (beta) to see some practices in action

Welcome! 3 Things You Ought To Know First

1. You are reading dozens of the best Node.js articles - this repository is a summary and curation of the top-ranked content on Node.js best practices, as well as content written here by collaborators

2. It is the largest compilation, and it is growing every week - currently, more than 80 best practices, style guides, and architectural tips are presented. New issues and pull requests are created every day to keep this live book updated. We'd love to see you contributing here, whether that is fixing code mistakes, helping with translations, or suggesting brilliant new ideas. See our writing guidelines here

3. Best practices have additional info - most bullets include a 🔗Read More link that expands on the practice with code examples, quotes from selected blogs, and more information

By Yoni Goldberg

Learn with me: As a consultant, I engage with worldwide teams on various activities like workshops and code reviews. 🎉AND... Hold on, I've just launched my beyond-the-basics testing course, which is on a 🎁 limited-time sale until August 7th

1. Project Architecture Practices (6)

1.1 Structure your solution by components #strategic #updated
1.2 Layer your components, keep the web layer within its boundaries #strategic #updated
1.3 Wrap common utilities as packages, consider publishing
1.4 Use environment aware, secure and hierarchical config #updated
1.5 Consider all the consequences when choosing the main framework #new
1.6 Use TypeScript sparingly and thoughtfully #new

2. Error Handling Practices (12)

2.1 Use Async-Await or promises for async error handling
2.2 Extend the built-in Error object #strategic #updated
2.3 Distinguish operational vs programmer errors #strategic #updated
2.4 Handle errors centrally, not within a middleware #strategic
2.5 Document API errors using OpenAPI or GraphQL
2.6 Exit the process gracefully when a stranger comes to town #strategic
2.7 Use a mature logger to increase errors visibility #updated
2.8 Test error flows using your favorite test framework #updated
2.9 Discover errors and downtime using APM products
2.10 Catch unhandled promise rejections #updated
2.11 Fail fast, validate arguments using a dedicated library
2.12 Always await promises before returning to avoid a partial stacktrace #new
2.13 Subscribe to event emitters 'error' event #new

3. Code Style Practices (12)

3.1 Use ESLint #strategic
3.2 Use Node.js eslint extension plugins #updated
3.3 Start a Codeblock's Curly Braces on the Same Line
3.4 Separate your statements properly
3.5 Name your functions
3.6 Use naming conventions for variables, constants, functions and classes
3.7 Prefer const over let. Ditch the var
3.8 Require modules first, not inside functions
3.9 Set an explicit entry point to a module/folder #updated
3.10 Use the === operator
3.11 Use Async Await, avoid callbacks #strategic
3.12 Use arrow function expressions (=>)
3.13 Avoid effects outside of functions #new

4. Testing And Overall Quality Practices (13)

4.1 At the very least, write API (component) testing #strategic
4.2 Include 3 parts in each test name #new
4.3 Structure tests by the AAA pattern #strategic
4.4 Ensure Node version is unified #new
4.5 Avoid global test fixtures and seeds, add data per-test #strategic
4.6 Tag your tests #advanced
4.7 Check your test coverage, it helps to identify wrong test patterns
4.8 Use production-like environment for e2e testing
4.9 Refactor regularly using static analysis tools
4.10 Mock responses of external HTTP services #advanced #new #advanced
4.11 Test your middlewares in isolation
4.12 Specify a port in production, randomize in testing #new
4.13 Test the five possible outcomes #strategic #new

5. Going To Production Practices (19)

5.1. Monitoring #strategic
5.2. Increase the observability using smart logging #strategic
5.3. Delegate anything possible (e.g. gzip, SSL) to a reverse proxy #strategic
5.4. Lock dependencies
5.5. Guard process uptime using the right tool
5.6. Utilize all CPU cores
5.7. Create a ‘maintenance endpoint’
5.8. Discover the unknowns using APM products #advanced #updated
5.9. Make your code production-ready
5.10. Measure and guard the memory usage #advanced
5.11. Get your frontend assets out of Node
5.12. Strive to be stateless #strategic
5.13. Use tools that automatically detect vulnerabilities
5.14. Assign a transaction id to each log statement #advanced
5.15. Set NODE_ENV=production
5.16. Design automated, atomic and zero-downtime deployments #advanced
5.17. Use an LTS release of Node.js
5.18. Log to stdout, avoid specifying log destination within the app #updated
5.19. Install your packages with npm ci #new

6. Security Practices (25)

6.1. Embrace linter security rules
6.2. Limit concurrent requests using a middleware
6.3 Extract secrets from config files or use packages to encrypt them #strategic
6.4. Prevent query injection vulnerabilities with ORM/ODM libraries #strategic
6.5. Collection of generic security best practices
6.6. Adjust the HTTP response headers for enhanced security
6.7. Constantly and automatically inspect for vulnerable dependencies #strategic
6.8. Protect Users' Passwords/Secrets using bcrypt or scrypt #strategic
6.9. Escape HTML, JS and CSS output
6.10. Validate incoming JSON schemas #strategic
6.11. Support blocklisting JWTs
6.12. Prevent brute-force attacks against authorization #advanced
6.13. Run Node.js as non-root user
6.14. Limit payload size using a reverse-proxy or a middleware
6.15. Avoid JavaScript eval statements
6.16. Prevent evil RegEx from overloading your single thread execution
6.17. Avoid module loading using a variable
6.18. Run unsafe code in a sandbox
6.19. Take extra care when working with child processes #advanced
6.20. Hide error details from clients
6.21. Configure 2FA for npm or Yarn #strategic
6.22. Modify session middleware settings
6.23. Avoid DOS attacks by explicitly setting when a process should crash #advanced
6.24. Prevent unsafe redirects
6.25. Avoid publishing secrets to the npm registry
6.26. 6.26 Inspect for outdated packages
6.27. Import built-in modules using the 'node:' protocol #new

7. Performance Practices (2) (Work In Progress️ ✍️)

7.1. Don't block the event loop
7.2. Prefer native JS methods over user-land utils like Lodash

8. Docker Practices (15)

8.1 Use multi-stage builds for leaner and more secure Docker images #strategic
8.2. Bootstrap using node command, avoid npm start
8.3. Let the Docker runtime handle replication and uptime #strategic
8.4. Use .dockerignore to prevent leaking secrets
8.5. Clean-up dependencies before production
8.6. Shutdown smartly and gracefully #advanced
8.7. Set memory limits using both Docker and v8 #advanced #strategic
8.8. Plan for efficient caching
8.9. Use explicit image reference, avoid latest tag
8.10. Prefer smaller Docker base images
8.11. Clean-out build-time secrets, avoid secrets in args #strategic #new
8.12. Scan images for multi layers of vulnerabilities #advanced
8.13 Clean NODE_MODULE cache
8.14. Generic Docker practices
8.15. Lint your Dockerfile #new

`1. Project Architecture Practices`

1.1 Structure your solution by business components

`📝 #updated`

TL;DR: The root of a system should contain folders or repositories that represent reasonably sized business modules. Each component represents a product domain (i.e., bounded context), like 'user-component', 'order-component', etc. Each component has its own API, logic, and logical database. What is the significant merit? With an autonomous component, every change is performed over a granular and smaller scope - the mental overload, development friction, and deployment fear are much smaller and better. As a result, developers can move much faster. This does not necessarily demand physical separation and can be achieved using a Monorepo or with a multi-repo

my-system
├─ apps (components)
│  ├─ orders
│  ├─ users
│  ├─ payments
├─ libraries (generic cross-component functionality)
│  ├─ logger
│  ├─ authenticator

Otherwise: when artifacts from various modules/topics are mixed together, there are great chances of a tightly-coupled 'spaghetti' system. For example, in an architecture where 'module-a controller' might call 'module-b service', there are no clear modularity borders - every code change might affect anything else. With this approach, developers who code new features struggle to realize the scope and impact of their change. Consequently, they fear breaking other modules, and each deployment becomes slower and riskier

1.2 Layer your components with 3-tiers, keep the web layer within its boundaries

`📝 #updated`

TL;DR: Each component should contain 'layers' - a dedicated folder for common concerns: 'entry-point' where controller lives, 'domain' where the logic lives, and 'data-access'. The primary principle of the most popular architectures is to separate the technical concerns (e.g., HTTP, DB, etc) from the pure logic of the app so a developer can code more features without worrying about infrastructural concerns. Putting each concern in a dedicated folder, also known as the 3-Tier pattern, is the simplest way to meet this goal

my-system
├─ apps (components)
│  ├─ component-a
   │  ├─ entry-points
   │  │  ├─ api # controller comes here
   │  │  ├─ message-queue # message consumer comes here
   │  ├─ domain # features and flows: DTO, services, logic
   │  ├─ data-access # DB calls w/o ORM

Otherwise: It's often seen that developer pass web objects like request/response to functions in the domain/logic layer - this violates the separation principle and makes it harder to access later the logic code by other clients like testing code, scheduled jobs, message queues, etc

🔗 Read More: layer your app

1.3 Wrap common utilities as packages, consider publishing

TL;DR: Place all reusable modules in a dedicated folder, e.g., "libraries", and underneath each module in its own folder, e.g., "/libraries/logger". Make the module an independent package with its own package.json file to increase the module encapsulation, and allows future publishing to a repository. In a Monorepo setup, modules can be consumed by 'npm linking' to their physical paths, using ts-paths or by publishing and installing from a package manager repository like the npm registry

my-system
├─ apps (components)
  │  ├─ component-a
├─ libraries (generic cross-component functionality)
│  ├─ logger
│  │  ├─ package.json
│  │  ├─ src
│  │  │ ├─ index.js

Otherwise: Clients of a module might import and get coupled to internal functionality of a module. With a package.json at the root, one can set a package.json.main or package.json.exports to explicitly tell which files and functions are part of the public interface

🔗 Read More: Structure by feature

1.4 Use environment aware, secure and hierarchical config

`📝 #updated`

TL;DR: A flawless configuration setup should ensure (a) keys can be read from file AND from environment variable (b) secrets are kept outside committed code (c) config is hierarchical for easier findability (d) typing support (e) validation for failing fast (f) Specify default for each key. There are a few packages that can help tick most of those boxes like convict, env-var, zod, and others

Otherwise: Consider a mandatory environment variable that wasn't provided. The app starts successfully and serve requests, some information is already persisted to DB. Then, it's realized that without this mandatory key the request can't complete, leaving the app in a dirty state

1.5 Consider all the consequences when choosing the main framework

`🌟 #new`

TL;DR: When building apps and APIs, using a framework is mandatory. It's easy to overlook alternative frameworks or important considerations and then finally land on a sub optimal option. As of 2023/2024, we believe that these four frameworks are worth considering: Nest.js, Fastify, express, and Koa. Click read more below for a detailed pros/cons of each framework. Simplistically, we believe that Nest.js is the best match for teams who wish to go OOP and/or build large-scale apps that can't get partitioned into smaller autonomous components. Fastify is our recommendation for apps with reasonably-sized components (e.g., Microservices) that are built around simple Node.js mechanics. Read our full considerations guide here

Otherwise: Due to the overwhelming amount of considerations, it's easy to make decisions based on partial information and compare apples with oranges. For example, it's believed that Fastify is a minimal web-server that should get compared with express only. In reality, it's a rich framework with many official plugins that cover many concerns

1.6 Use TypeScript sparingly and thoughtfully

`🌟 #new`

TL;DR: Coding without type safety is no longer an option, TypeScript is the most popular option for this mission. Use it to define variables and functions return types. With that, it is also a double edge sword that can greatly encourage complexity with its additional ~ 50 keywords and sophisticated features. Consider using it sparingly, mostly with simple types, and utilize advanced features only when a real need arises

Otherwise: Researches show that using TypeScript can help in detecting ~20% bugs earlier. Without it, also the developer experience in the IDE is intolerable. On the flip side, 80% of other bugs were not discovered using types. Consequently, typed syntax is valuable but limited. Only efficient tests can discover the whole spectrum of bugs, including type-related bugs. It might also defeat its purpose: sophisticated code features are likely to increase the code complexity, which by itself increases both the amount of bugs and the average bug fix time

⬆ Return to top

`2. Error Handling Practices`

2.1 Use Async-Await or promises for async error handling

TL;DR: Handling async errors in callback style is probably the fastest way to hell (a.k.a the pyramid of doom). The best gift you can give to your code is using Promises with async-await which enables a much more compact and familiar code syntax like try-catch

Otherwise: Node.js callback style, function(err, response), is a promising way to un-maintainable code due to the mix of error handling with casual code, excessive nesting, and awkward coding patterns

🔗 Read More: avoiding callbacks

2.2 Extend the built-in Error object

`📝 #updated`

TL;DR: Some libraries throw errors as a string or as some custom type – this complicates the error handling logic and the interoperability between modules. Instead, create app error object/class that extends the built-in Error object and use it whenever rejecting, throwing or emitting an error. The app error should add useful imperative properties like the error name/code and isCatastrophic. By doing so, all errors have a unified structure and support better error handling. There is no-throw-literal ESLint rule that strictly checks that (although it has some limitations which can be solved when using TypeScript and setting the @typescript-eslint/no-throw-literal rule)

Otherwise: When invoking some component, being uncertain which type of errors come in return – it makes proper error handling much harder. Even worse, using custom types to describe errors might lead to loss of critical error information like the stack trace!

2.3 Distinguish catastrophic errors from operational errors

`📝 #updated`

TL;DR: Operational errors (e.g. API received an invalid input) refer to known cases where the error impact is fully understood and can be handled thoughtfully. On the other hand, catastrophic error (also known as programmer errors) refers to unusual code failures that dictate to gracefully restart the application

Otherwise: You may always restart the application when an error appears, but why let ~5000 online users down because of a minor, predicted, operational error? The opposite is also not ideal – keeping the application up when an unknown catastrophic issue (programmer error) occurred might lead to an unpredicted behavior. Differentiating the two allows acting tactfully and applying a balanced approach based on the given context

2.4 Handle errors centrally, not within a middleware

TL;DR: Error handling logic such as logging, deciding whether to crash and monitoring metrics should be encapsulated in a dedicated and centralized object that all entry-points (e.g. APIs, cron jobs, scheduled jobs) call when an error comes in

Otherwise: Not handling errors within a single place will lead to code duplication and probably to improperly handled errors

2.5 Document API errors using OpenAPI or GraphQL

TL;DR: Let your API callers know which errors might come in return so they can handle these thoughtfully without crashing. For RESTful APIs, this is usually done with documentation frameworks like OpenAPI. If you're using GraphQL, you can utilize your schema and comments as well

Otherwise: An API client might decide to crash and restart only because it received back an error it couldn’t understand. Note: the caller of your API might be you (very typical in a microservice environment)

2.6 Exit the process gracefully when a stranger comes to town

TL;DR: When an unknown error occurs (catastrophic error, see best practice 2.3) - there is uncertainty about the application healthiness. In this case, there is no escape from making the error observable, shutting off connections and exiting the process. Any reputable runtime framework like Dockerized services or cloud serverless solutions will take care to restart

Otherwise: When an unfamiliar exception occurs, some object might be in a faulty state (e.g. an event emitter which is used globally and not firing events anymore due to some internal failure) and all future requests might fail or behave crazily

🔗 Read More: shutting the process

2.7 Use a mature logger to increase errors visibility

`📝 #updated`

TL;DR: A robust logging tools like Pino or Winston increases the errors visibility using features like log-levels, pretty print coloring and more. Console.log lacks these imperative features and should be avoided. The best in class logger allows attaching custom useful properties to log entries with minimized serialization performance penalty. Developers should write logs to stdout and let the infrastructure pipe the stream to the appropriate log aggregator

Otherwise: Skimming through console.logs or manually through messy text file without querying tools or a decent log viewer might keep you busy at work until late

🔗 Read More: using a mature logger

2.8 Test error flows using your favorite test framework

`📝 #updated`

TL;DR: Whether professional automated QA or plain manual developer testing – Ensure that your code not only satisfies positive scenarios but also handles and returns the right errors. On top of this, simulate deeper error flows like uncaught exceptions and ensure that the error handler treat these properly (see code examples within the "read more" section)

Otherwise: Without testing, whether automatically or manually, you can’t rely on your code to return the right errors. Without meaningful errors – there’s no error handling

🔗 Read More: testing error flows

2.9 Discover errors and downtime using APM products

TL;DR: Monitoring and performance products (a.k.a APM) proactively gauge your codebase or API so they can automagically highlight errors, crashes, and slow parts that you were missing

Otherwise: You might spend great effort on measuring API performance and downtimes, probably you’ll never be aware which are your slowest code parts under real-world scenario and how these affect the UX

🔗 Read More: using APM products

2.10 Catch unhandled promise rejections

`📝 #updated`

TL;DR: Any exception thrown within a promise will get swallowed and discarded unless a developer didn’t forget to explicitly handle it. Even if your code is subscribed to process.uncaughtException! Overcome this by registering to the event process.unhandledRejection

Otherwise: Your errors will get swallowed and leave no trace. Nothing to worry about

2.11 Fail fast, validate arguments using a dedicated library

TL;DR: Assert API input to avoid nasty bugs that are much harder to track later. The validation code is usually tedious unless you are using a modern validation library like ajv, zod, or typebox

Otherwise: Consider this – your function expects a numeric argument “Discount” which the caller forgets to pass, later on, your code checks if Discount!=0 (amount of allowed discount is greater than zero), then it will allow the user to enjoy a discount. OMG, what a nasty bug. Can you see it?

🔗 Read More: failing fast

2.12 Always await promises before returning to avoid a partial stacktrace

`🌟 #new`

TL;DR: Always do return await when returning a promise to benefit full error stacktrace. If a function returns a promise, that function must be declared as async function and explicitly await the promise before returning it

Otherwise: The function that returns a promise without awaiting won't appear in the stacktrace. Such missing frames would probably complicate the understanding of the flow that leads to the error, especially if the cause of the abnormal behavior is inside of the missing function

🔗 Read More: returning promises

2.13 Subscribe to event emitters and streams 'error' event

`🌟 #new`

TL;DR: Unlike typical functions, a try-catch clause won't get errors that originate from Event Emitters and anything inherited from it (e.g., streams). Instead of try-catch, subscribe to an event emitter's 'error' event so your code can handle the error in context. When dealing with EventTargets (the web standard version of Event Emitters) there are no 'error' event and all errors end in the process.on('error) global event - in this case, at least ensure that the process crash or not based on the desired context. Also, mind that error originating from asynchronous event handlers are not get caught unless the event emitter is initialized with {captureRejections: true}

Otherwise: Event emitters are commonly used for global and key application functionality such as DB or message queue connection. When this kind of crucial objects throw an error, at best the process will crash due to unhandled exception. Even worst, it will stay alive as a zombie while a key functionality is turned off

⬆ Return to top

`3. Code Patterns And Style Practices`

3.1 Use ESLint

TL;DR: ESLint is the de-facto standard for checking possible code errors and fixing code style, not only to identify nitty-gritty spacing issues but also to detect serious code anti-patterns like developers throwing errors without classification. Though ESLint can automatically fix code styles, other tools like prettier are more powerful in formatting the fix and work in conjunction with ESLint

Otherwise: Developers will focus on tedious spacing and line-width concerns and time might be wasted overthinking the project's code style

3.2 Use Node.js eslint extension plugins

`📝 #updated`

TL;DR: On top of ESLint standard rules that cover vanilla JavaScript, add Node.js specific plugins like eslint-plugin-node, eslint-plugin-mocha and eslint-plugin-node-security, eslint-plugin-require, /eslint-plugin-jest and other useful rules

Otherwise: Many faulty Node.js code patterns might escape under the radar. For example, developers might require(variableAsPath) files with a variable given as a path which allows attackers to execute any JS script. Node.js linters can detect such patterns and complain early

3.3 Start a Codeblock's Curly Braces on the Same Line

TL;DR: The opening curly braces of a code block should be on the same line as the opening statement

Code Example

// Do
function someFunction() {
  // code block
}

// Avoid
function someFunction()
{
  // code block
}

Otherwise: Deferring from this best practice might lead to unexpected results, as seen in the StackOverflow thread below:

3.4 Separate your statements properly

No matter if you use semicolons or not to separate your statements, knowing the common pitfalls of improper linebreaks or automatic semicolon insertion, will help you to eliminate regular syntax errors.

TL;DR: Use ESLint to gain awareness about separation concerns. Prettier or Standardjs can automatically resolve these issues.

Otherwise: As seen in the previous section, JavaScript's interpreter automatically adds a semicolon at the end of a statement if there isn't one, or considers a statement as not ended where it should, which might lead to some undesired results. You can use assignments and avoid using immediately invoked function expressions to prevent most of the unexpected errors.

Code example

// Do
function doThing() {
    // ...
}

doThing()

// Do

const items = [1, 2, 3]
items.forEach(console.log)

// Avoid — throws exception
const m = new Map()
const a = [1,2,3]
[...m.values()].forEach(console.log)
> [...m.values()].forEach(console.log)
>  ^^^
> SyntaxError: Unexpected token ...

// Avoid — throws exception
const count = 2 // it tries to run 2(), but 2 is not a function
(function doSomething() {
  // do something amazing
}())
// put a semicolon before the immediate invoked function, after the const definition, save the return value of the anonymous function to a variable or avoid IIFEs altogether

3.5 Name your functions

TL;DR: Name all functions, including closures and callbacks. Avoid anonymous functions. This is especially useful when profiling a node app. Naming all functions will allow you to easily understand what you're looking at when checking a memory snapshot

Otherwise: Debugging production issues using a core dump (memory snapshot) might become challenging as you notice significant memory consumption from anonymous functions

3.6 Use naming conventions for variables, constants, functions and classes

TL;DR: Use lowerCamelCase when naming constants, variables and functions, UpperCamelCase (capital first letter as well) when naming classes and UPPER_SNAKE_CASE when naming global or static variables. This will help you to easily distinguish between plain variables, functions, classes that require instantiation and variables declared at global module scope. Use descriptive names, but try to keep them short

Otherwise: JavaScript is the only language in the world that allows invoking a constructor ("Class") directly without instantiating it first. Consequently, Classes and function-constructors are differentiated by starting with UpperCamelCase

3.6 Code Example

// for global variables names we use the const/let keyword and UPPER_SNAKE_CASE
let MUTABLE_GLOBAL = "mutable value";
const GLOBAL_CONSTANT = "immutable value";
const CONFIG = {
  key: "value",
};

// examples of UPPER_SNAKE_CASE convention in nodejs/javascript ecosystem
// in javascript Math.PI module
const PI = 3.141592653589793;

// https://github.com/nodejs/node/blob/b9f36062d7b5c5039498e98d2f2c180dca2a7065/lib/internal/http2/core.js#L303
// in nodejs http2 module
const HTTP_STATUS_OK = 200;
const HTTP_STATUS_CREATED = 201;

// for class name we use UpperCamelCase
class SomeClassExample {
  // for static class properties we use UPPER_SNAKE_CASE
  static STATIC_PROPERTY = "value";
}

// for functions names we use lowerCamelCase
function doSomething() {
  // for scoped variable names we use the const/let keyword and lowerCamelCase
  const someConstExample = "immutable value";
  let someMutableExample = "mutable value";
}

3.7 Prefer const over let. Ditch the var

TL;DR: Using const means that once a variable is assigned, it cannot be reassigned. Preferring const will help you to not be tempted to use the same variable for different uses, and make your code clearer. If a variable needs to be reassigned, in a for loop, for example, use let to declare it. Another important aspect of let is that a variable declared using it is only available in the block scope in which it was defined. var is function scoped, not block-scoped, and shouldn't be used in ES6 now that you have const and let at your disposal

Otherwise: Debugging becomes way more cumbersome when following a variable that frequently changes

3.8 Require modules first, not inside functions

TL;DR: Require modules at the beginning of each file, before and outside of any functions. This simple best practice will not only help you easily and quickly tell the dependencies of a file right at the top but also avoids a couple of potential problems

Otherwise: Requires are run synchronously by Node.js. If they are called from within a function, it may block other requests from being handled at a more critical time. Also, if a required module or any of its dependencies throw an error and crash the server, it is best to find out about it as soon as possible, which might not be the case if that module is required from within a function

3.9 Set an explicit entry point to a module/folder

`📝 #updated`

TL;DR: When developing a module/library, set an explicit root file that exports the public and interesting code. Discourage the client code from importing deep files and becoming familiar with the internal structure. With commonjs (require), this can be done with an index.js file at the folder's root or the package.json.main field. With ESM (import), if a package.json exists on the root, the field "exports" allow specifying the module's root file. If no package.json exists, you may put an index.js file on the root which re-exports all the public functionality

Otherwise: Having an explicit root file acts like a public 'interface' that encapsulates the internal, directs the caller to the public code and facilitates future changes without breaking the contract

3.9 Code example - avoid coupling the client to the module structure

// Avoid: client has deep familiarity with the internals

// Client code
const SMSWithMedia = require("./SMSProvider/providers/media/media-provider.js");

// Better: explicitly export the public functions

//index.js, module code
module.exports.SMSWithMedia = require("./SMSProvider/providers/media/media-provider.js");

// Client code
const { SMSWithMedia } = require("./SMSProvider");

3.10 Use the `===` operator

TL;DR: Prefer the strict equality operator === over the weaker abstract equality operator ==. == will compare two variables after converting them to a common type. There is no type conversion in ===, and both variables must be of the same type to be equal

Otherwise: Unequal variables might return true when compared with the == operator

3.10 Code example

"" == "0"; // false
0 == ""; // true
0 == "0"; // true

false == "false"; // false
false == "0"; // true

false == undefined; // false
false == null; // false
null == undefined; // true

" \t\r\n " == 0; // true

All statements above will return false if used with ===

3.11 Use Async Await, avoid callbacks

TL;DR: Async-await is the simplest way to express an asynchronous flow as it makes asynchronous code look synchronous. Async-await will also result in much more compact code and support for try-catch. This technique now supersedes callbacks and promises in most cases. Using it in your code is probably the best gift one can give to the code reader

Otherwise: Handling async errors in callback style are probably the fastest way to hell - this style forces to check errors all over, deal with awkward code nesting, and makes it difficult to reason about the code flow

3.12 Use arrow function expressions (=>)

TL;DR: Though it's recommended to use async-await and avoid function parameters when dealing with older APIs that accept promises or callbacks - arrow functions make the code structure more compact and keep the lexical context of the root function (i.e. this)

Otherwise: Longer code (in ES5 functions) is more prone to bugs and cumbersome to read

3.13 Avoid effects outside of functions

`🌟 #new`

TL;DR: Avoid putting code with effects like network or DB calls outside of functions. Such a code will be executed immediately when another file requires the file. This 'floating' code might get executed when the underlying system is not ready yet. It also comes with a performance penalty even when this module's functions will finally not be used in runtime. Last, mocking these DB/network calls for testing is harder outside of functions. Instead, put this code inside functions that should get called explicitly. If some DB/network code must get executed right when the module loads, consider using the factory or revealing module patterns

Otherwise: A typical web framework sets error handler, environment variables and monitoring. When DB/network calls are made before the web framework is initialized, they won't be monitored or fail due to a lack of configuration data

⬆ Return to top

`4. Testing And Overall Quality Practices`

_We have dedicated guides for testing, see below. The best practices list here is a brief summary of these guides

a. JavaScript testing best practices b. Node.js testing - beyond the basics _

4.1 At the very least, write API (component) testing

TL;DR: Most projects just don't have any automated testing due to short timetables or often the 'testing project' ran out of control and was abandoned. For that reason, prioritize and start with API testing which is the easiest way to write and provides more coverage than unit testing (you may even craft API tests without code using tools like Postman). Afterwards, should you have more resources and time, continue with advanced test types like unit testing, DB testing, performance testing, etc

Otherwise: You may spend long days on writing unit tests to find out that you got only 20% system coverage

4.2 Include 3 parts in each test name

`🌟 #new`

TL;DR: Make the test speak at the requirements level so it's self-explanatory also to QA engineers and developers who are not familiar with the code internals. State in the test name what is being tested (unit under test), under what circumstances, and what is the expected result

Otherwise: A deployment just failed, a test named “Add product” failed. Does this tell you what exactly is malfunctioning?

4.3 Structure tests by the AAA pattern

`🌟 #new`

TL;DR: Structure your tests with 3 well-separated sections: Arrange, Act & Assert (AAA). The first part includes the test setup, then the execution of the unit under test, and finally the assertion phase. Following this structure guarantees that the reader spends no brain CPU on understanding the test plan

Otherwise: Not only you spend long daily hours on understanding the main code, but now also what should have been the simple part of the day (testing) stretches your brain

4.4 Ensure Node version is unified

`🌟 #new`

TL;DR: Use tools that encourage or enforce the same Node.js version across different environments and developers. Tools like nvm, and Volta allow specifying the project's version in a file so each team member can run a single command to conform with the project's version. Optionally, this definition can be replicated to CI and the production runtime (e.g., copy the specified value to .Dockerfile build and to the CI declaration file)

Otherwise: A developer might face or miss an error because she uses a different Node.js version than her teammates. Even worse - the production runtime might be different than the environment where tests were executed

4.5 Avoid global test fixtures and seeds, add data per-test

TL;DR: To prevent test coupling and easily reason about the test flow, each test should add and act on its own set of DB rows. Whenever a test needs to pull or assume the existence of some DB data - it must explicitly add that data and avoid mutating any other records

Otherwise: Consider a scenario where deployment is aborted due to failing tests, team is now going to spend precious investigation time that ends in a sad conclusion: the system works well, the tests however interfere with each other and break the build

4.6 Tag your tests

TL;DR: Different tests must run on different scenarios: quick smoke, IO-less, tests should run when a developer saves or commits a file, full end-to-end tests usually run when a new pull request is submitted, etc. This can be achieved by tagging tests with keywords like #cold #api #sanity so you can grep with your testing harness and invoke the desired subset. For example, this is how you would invoke only the sanity test group with Mocha: mocha --grep 'sanity'

Otherwise: Running all the tests, including tests that perform dozens of DB queries, any time a developer makes a small change can be extremely slow and keeps developers away from running tests

4.7 Check your test coverage, it helps to identify wrong test patterns

TL;DR: Code coverage tools like Istanbul/NYC are great for 3 reasons: it comes for free (no effort is required to benefit this reports), it helps to identify a decrease in testing coverage, and last but not least it highlights testing mismatches: by looking at colored code coverage reports you may notice, for example, code areas that are never tested like catch clauses (meaning that tests only invoke the happy paths and not how the app behaves on errors). Set it to fail builds if the coverage falls under a certain threshold

Otherwise: There won't be any automated metric telling you when a large portion of your code is not covered by testing

4.8 Use production-like environment for e2e testing

TL;DR: End to end (e2e) testing which includes live data used to be the weakest link of the CI process as it depends on multiple heavy services like DB. Use an environment which is as close to your real production environment as possible like a-continue (Missed -continue here, needs content. Judging by the Otherwise clause, this should mention docker-compose)

Otherwise: Without docker-compose, teams must maintain a testing DB for each testing environment including developers' machines, keep all those DBs in sync so test results won't vary across environments

4.9 Refactor regularly using static analysis tools

TL;DR: Using static analysis tools helps by giving objective ways to improve code quality and keeps your code maintainable. You can add static analysis tools to your CI build to fail when it finds code smells. Its main selling points over plain linting are the ability to inspect quality in the context of multiple files (e.g. detect duplications), perform advanced analysis (e.g. code complexity), and follow the history and progress of code issues. Two examples of tools you can use are Sonarqube (2,600+ stars) and Code Climate (1,500+ stars).

Otherwise: With poor code quality, bugs and performance will always be an issue that no shiny new library or state of the art features can fix

🔗 Read More: Refactoring!

4.10 Mock responses of external HTTP services

`🌟 #new`

TL;DR: Use network mocking tools to simulate responses of external collaborators' services that are approached over the network (e.g., REST, Graph). This is imperative not only to isolate the component under test but mostly to simulate non-happy path flows. Tools like nock (in-process) or Mock-Server allow defining a specific response of external service in a single line of code. Remember to simulate also errors, delays, timeouts, and any other event that is likely to happen in production

Otherwise: Allowing your component to reach real external services instances will likely result in naive tests that mostly cover happy paths. The tests might also be flaky and slow

🔗 Read More: Mock external services

4.11 Test your middlewares in isolation

TL;DR: When a middleware holds some immense logic that spans many requests, it is worth testing it in isolation without waking up the entire web framework. This can be easily achieved by stubbing and spying on the {req, res, next} objects

Otherwise: A bug in Express middleware === a bug in all or most requests

4.12 Specify a port in production, randomize in testing

`🌟 #new`

TL;DR: When testing against the API, it's common and desirable to initialize the web server inside the tests. Let the server randomize the web server port in testing to prevent collisions. If you're using Node.js http server (used by most frameworks), doing so demands nothing but passing a port number zero - this will randomize an available port

Otherwise: Specifying a fixed port will prevent two testing processes from running at the same time. Most of the modern test runners run with multiple processes by default

4.13 Test the five possible outcomes

`🌟 #new`

TL;DR: When testing a flow, ensure to cover five potential categories. Any time some action is triggered (e.g., API call), a reaction occurs, a meaningful outcome is produced and calls for testing. There are five possible outcome types for every flow: a response, a visible state change (e.g., DB), an outgoing API call, a new message in a queue, and an observability call (e.g., logging, metric). See a checklist here. Each type of outcome comes with unique challenges and techniques to mitigate those challenges - we have a dedicated guide about this topic: Node.js testing - beyond the basics

Otherwise: Consider a case when testing the addition of a new product to the system. It's common to see tests that assert on a valid response only. What if the product was failed to persist regardless of the positive response? what if when adding a new product demands calling some external service, or putting a message in the queue - shouldn't the test assert these outcomes as well? It's easy to overlook various paths, this is where a checklist comes handy

🔗 Read More: Test five outcomes

⬆ Return to top

`5. Going To Production Practices`

5.1. Monitoring

TL;DR: Monitoring is a game of finding out issues before customers do – obviously this should be assigned unprecedented importance. The market is overwhelmed with offers thus consider starting with defining the basic metrics you must follow (my suggestions inside), then go over additional fancy features and choose the solution that ticks all boxes. In any case, the 4 layers of observability must be covered: uptime, metrics with focus on user-facing symptoms and Node.js technical metrics like event loop lag, distributed flows measurement with Open Telemetry and logging. Click ‘Read More’ below for an overview of the solutions

Otherwise: Failure === disappointed customers. Simple

🔗 Read More: Monitoring!

5.2. Increase the observability using smart logging

TL;DR: Logs can be a dumb warehouse of debug statements or the enabler of a beautiful dashboard that tells the story of your app. Plan your logging platform from day 1: how logs are collected, stored and analyzed to ensure that the desired information (e.g. error rate, following an entire transaction through services and servers, etc) can really be extracted

Otherwise: You end up with a black box that is hard to reason about, then you start re-writing all logging statements to add additional information

5.3. Delegate anything possible (e.g. gzip, SSL) to a reverse proxy

TL;DR: Node is quite bad at doing CPU intensive tasks like gzipping, SSL termination, etc. You should use specialized infrastructure like nginx, HAproxy or cloud vendor services instead

Otherwise: Your poor single thread will stay busy doing infrastructural tasks instead of dealing with your application core and performance will degrade accordingly

5.4. Lock dependencies

TL;DR: Your code must be identical across all environments, but without a special lockfile npm lets dependencies drift across environments. Ensure to commit your package-lock.json so all the environments will be identical

Otherwise: QA will thoroughly test the code and approve a version that will behave differently in production. Even worse, different servers in the same production cluster might run different code

🔗 Read More: Lock dependencies

5.5. Guard process uptime using the right tool

TL;DR: The process must go on and get restarted upon failures. Modern runtime platforms like Docker-ized platforms (e.g. Kubernetes), and Serverless take care for this automatically. When the app is hosted on a bare metal server, one must take care for a process management tools like systemd. Avoid including a custom process management tool in a modern platform that monitors an app instance (e.g., Kubernetes) - doing so will hide failures from the infrastructure. When the underlying infrastructure is not aware of errors, it can't perform useful mitigation steps like re-placing the instance in a different location

Otherwise: Running dozens of instances without a clear strategy and too many tools together (cluster management, docker, PM2) might lead to DevOps chaos

5.6. Utilize all CPU cores

TL;DR: At its basic form, a Node app runs on a single CPU core while all others are left idling. It’s your duty to replicate the Node process and utilize all CPUs. Most of the modern run-times platform (e.g., Kubernetes) allow replicating instances of the app but they won't verify that all cores are utilized - this is your duty. If the app is hosted on a bare server, it's also your duty to use some process replication solution (e.g. systemd)

Otherwise: Your app will likely utilize only 25% of its available resources(!) or even less. Note that a typical server has 4 CPU cores or more, naive deployment of Node.js utilizes only 1 (even using PaaS services like AWS beanstalk!)

🔗 Read More: Utilize all CPU cores

5.7. Create a ‘maintenance endpoint’

TL;DR: Expose a set of system-related information, like memory usage and REPL, etc in a secured API. Although it’s highly recommended to rely on standard and battle-tested tools, some valuable information and operations are easier done using code

Otherwise: You’ll find that you’re performing many “diagnostic deploys” – shipping code to production only to extract some information for diagnostic purposes

5.8. Discover the unknowns using APM products

`📝 #updated`

TL;DR: Consider adding another safety layer to the production stack - APM. While the majority of symptoms and causes can be detected using traditional monitoring techniques, in a distributed system there is more than meets the eye. Application monitoring and performance products (a.k.a. APM) can auto-magically go beyond traditional monitoring and provide additional layer of discovery and developer-experience. For example, some APM products can highlight a transaction that loads too slow on the end-user's side while suggesting the root cause. APMs also provide more context for developers who try to troubleshoot a log error by showing what was the server busy with when the error occurred. To name a few example

Otherwise: You might spend great effort on measuring API performance and downtimes, probably you’ll never be aware which is your slowest code parts under real-world scenario and how these affect the UX

5.9. Make your code production-ready

TL;DR: Code with the end in mind, plan for production from day 1. This sounds a bit vague so I’ve compiled a few development tips that are closely related to production maintenance (click 'Read More')

Otherwise: A world champion IT/DevOps guy won’t save a system that is badly written

5.10. Measure and guard the memory usage

TL;DR: Node.js has controversial relationships with memory: the v8 engine has soft limits on memory usage (1.4GB) and there are known paths to leak memory in Node’s code – thus watching Node’s process memory is a must. In small apps, you may gauge memory periodically using shell commands but in medium-large apps consider baking your memory watch into a robust monitoring system

Otherwise: Your process memory might leak a hundred megabytes a day like how it happened at Walmart

5.11. Get your frontend assets out of Node

TL;DR: Serve frontend content using a specialized infrastructure (nginx, S3, CDN) because Node performance gets hurt when dealing with many static files due to its single-threaded model. One exception to this guideline is when doing server-side rendering

Otherwise: Your single Node thread will be busy streaming hundreds of html/images/angular/react files instead of allocating all its resources for the task it was born for – serving dynamic content

5.12. Strive to be stateless

TL;DR: Store any type of data (e.g. user sessions, cache, uploaded files) within external data stores. When the app holds data in-process this adds additional layer of maintenance complexity like routing users to the same instance and higher cost of restarting a process. To enforce and encourage a stateless approach, most modern runtime platforms allows 'reapp-ing' instances periodically

Otherwise: Failure at a given server will result in application downtime instead of just killing a faulty machine. Moreover, scaling-out elasticity will get more challenging due to the reliance on a specific server

5.13. Use tools that automatically detect vulnerabilities

TL;DR: Even the most reputable dependencies such as Express have known vulnerabilities (from time to time) that can put a system at risk. This can be easily tamed using community and commercial tools that constantly check for vulnerabilities and warn (locally or at GitHub), some can even patch them immediately

Otherwise: Keeping your code clean from vulnerabilities without dedicated tools will require you to constantly follow online publications about new threats. Quite tedious

5.14. Assign a transaction id to each log statement

TL;DR: Assign the same identifier, transaction-id: uuid(), to each log entry within a single request (also known as correlation-id/tracing-id/request-context). Then when inspecting errors in logs, easily conclude what happened before and after. Node has a built-in mechanism, AsyncLocalStorage, for keeping the same context across asynchronous calls. see code examples inside

Otherwise: Looking at a production error log without the context – what happened before – makes it much harder and slower to reason about the issue

5.15. Set `NODE_ENV=production`

TL;DR: Set the environment variable NODE_ENV to ‘production’ or ‘development’ to flag whether production optimizations should get activated – some npm packages determine the current environment and optimize their code for production

Otherwise: Omitting this simple property might greatly degrade performance when dealing with some specific libraries like Express server-side rendering

5.16. Design automated, atomic and zero-downtime deployments

TL;DR: Research shows that teams who perform many deployments lower the probability of severe production issues. Fast and automated deployments that don’t require risky manual steps and service downtime significantly improve the deployment process. You should probably achieve this using Docker combined with CI tools as they became the industry standard for streamlined deployment

Otherwise: Long deployments -> production downtime & human-related error -> team unconfident in making deployment -> fewer deployments and features

5.17. Use an LTS release of Node.js

TL;DR: Ensure you are using an LTS version of Node.js to receive critical bug fixes, security updates and performance improvements

Otherwise: Newly discovered bugs or vulnerabilities could be used to exploit an application running in production, and your application may become unsupported by various modules and harder to maintain

5.18. Log to stdout, avoid specifying log destination within the app

`📝 #updated`

TL;DR: Log destinations should not be hard-coded by developers within the application code, but instead should be defined by the execution environment the application runs in. Developers should write logs to stdout using a logger utility and then let the execution environment (container, server, etc.) pipe the stdout stream to the appropriate destination (i.e. Splunk, Graylog, ElasticSearch, etc.).

Otherwise: If developers set the log routing, less flexibility is left for the ops professional who wishes to customize it. Beyond this, if the app tries to log directly to a remote location (e.g., Elastic Search), in case of panic or crash - further logs that might explain the problem won't arrive

🔗 Read More: Log Routing

5.19. Install your packages with `npm ci`

TL;DR: Run npm ci to strictly do a clean install of your dependencies matching package.json and package-lock.json. Obviously production code must use the exact version of the packages that were used for testing. While package-lock.json file sets strict version for dependencies, in case of mismatch with the file package.json, the command 'npm install' will treat package.json as the source of truth. On the other hand, the command 'npm ci' will exit with error in case of mismatch between these files

Otherwise: QA will thoroughly test the code and approve a version that will behave differently in production. Even worse, different servers in the same production cluster might run different code.

🔗 Read More: Use npm ci

⬆ Return to top

`6. Security Best Practices`

6.1. Embrace linter security rules

TL;DR: Make use of security-related linter plugins such as eslint-plugin-security to catch security vulnerabilities and issues as early as possible, preferably while they're being coded. This can help catching security weaknesses like using eval, invoking a child process or importing a module with a string literal (e.g. user input). Click 'Read more' below to see code examples that will get caught by a security linter

Otherwise: What could have been a straightforward security weakness during development becomes a major issue in production. Also, the project may not follow consistent code security practices, leading to vulnerabilities being introduced, or sensitive secrets committed into remote repositories

🔗 Read More: Lint rules

6.2. Limit concurrent requests using a middleware

TL;DR: DOS attacks are very popular and relatively easy to conduct. Implement rate limiting using an external service such as cloud load balancers, cloud firewalls, nginx, rate-limiter-flexible package, or (for smaller and less critical apps) a rate-limiting middleware (e.g. express-rate-limit)

Otherwise: An application could be subject to an attack resulting in a denial of service where real users receive a degraded or unavailable service.

6.3 Extract secrets from config files or use packages to encrypt them

TL;DR: Never store plain-text secrets in configuration files or source code. Instead, make use of secret-management systems like Vault products, Kubernetes/Docker Secrets, or using environment variables. As a last resort, secrets stored in source control must be encrypted and managed (rolling keys, expiring, auditing, etc). Make use of pre-commit/push hooks to prevent committing secrets accidentally

Otherwise: Source control, even for private repositories, can mistakenly be made public, at which point all secrets are exposed. Access to source control for an external party will inadvertently provide access to related systems (databases, apis, services, etc).

🔗 Read More: Secret management

6.4. Prevent query injection vulnerabilities with ORM/ODM libraries

TL;DR: To prevent SQL/NoSQL injection and other malicious attacks, always make use of an ORM/ODM or a database library that escapes data or supports named or indexed parameterized queries, and takes care of validating user input for expected types. Never just use JavaScript template strings or string concatenation to inject values into queries as this opens your application to a wide spectrum of vulnerabilities. All the reputable Node.js data access libraries (e.g. Sequelize, Knex, mongoose) have built-in protection against injection attacks.

Otherwise: Unvalidated or unsanitized user input could lead to operator injection when working with MongoDB for NoSQL, and not using a proper sanitization system or ORM will easily allow SQL injection attacks, creating a giant vulnerability.

6.5. Collection of generic security best practices

TL;DR: This is a collection of security advice that is not related directly to Node.js - the Node implementation is not much different than any other language. Click read more to skim through.

6.6. Adjust the HTTP response headers for enhanced security

TL;DR: Your application should be using secure headers to prevent attackers from using common attacks like cross-site scripting (XSS), clickjacking and other malicious attacks. These can be configured easily using modules like helmet.

Otherwise: Attackers could perform direct attacks on your application's users, leading to huge security vulnerabilities

6.7. Constantly and automatically inspect for vulnerable dependencies

TL;DR: With the npm ecosystem it is common to have many dependencies for a project. Dependencies should always be kept in check as new vulnerabilities are found. Use tools like npm audit or snyk to track, monitor and patch vulnerable dependencies. Integrate these tools with your CI setup so you catch a vulnerable dependency before it makes it to production.

Otherwise: An attacker could detect your web framework and attack all its known vulnerabilities.

🔗 Read More: Dependency security

6.8. Protect Users' Passwords/Secrets using bcrypt or scrypt

TL;DR: Passwords or secrets (e.g. API keys) should be stored using a secure hash + salt function like bcrypt,scrypt, or worst case pbkdf2.

Otherwise: Passwords and secrets that are stored without using a secure function are vulnerable to brute forcing and dictionary attacks that will lead to their disclosure eventually.

🔗 Read More: User Passwords

6.9. Escape HTML, JS and CSS output

TL;DR: Untrusted data that is sent down to the browser might get executed instead of just being displayed, this is commonly referred as a cross-site-scripting (XSS) attack. Mitigate this by using dedicated libraries that explicitly mark the data as pure content that should never get executed (i.e. encoding, escaping)

Otherwise: An attacker might store malicious JavaScript code in your DB which will then be sent as-is to the poor clients

🔗 Read More: Escape output

6.10. Validate incoming JSON schemas

TL;DR: Validate the incoming requests' body payload and ensure it meets expectations, fail fast if it doesn't. To avoid tedious validation coding within each route you may use lightweight JSON-based validation schemas such as jsonschema or joi

Otherwise: Your generosity and permissive approach greatly increases the attack surface and encourages the attacker to try out many inputs until they find some combination to crash the application

6.11. Support blocklisting JWTs

TL;DR: When using JSON Web Tokens (for example, with Passport.js), by default there's no mechanism to revoke access from issued tokens. Once you discover some malicious user activity, there's no way to stop them from accessing the system as long as they hold a valid token. Mitigate this by implementing a blocklist of untrusted tokens that are validated on each request.

Otherwise: Expired, or misplaced tokens could be used maliciously by a third party to access an application and impersonate the owner of the token.

6.12. Prevent brute-force attacks against authorization

TL;DR: A simple and powerful technique is to limit authorization attempts using two metrics:

The first is number of consecutive failed attempts by the same user unique ID/name and IP address.
The second is number of failed attempts from an IP address over some long period of time. For example, block an IP address if it makes 100 failed attempts in one day.

Otherwise: An attacker can issue unlimited automated password attempts to gain access to privileged accounts on an application

🔗 Read More: Login rate limiting

6.13. Run Node.js as non-root user

TL;DR: There is a common scenario where Node.js runs as a root user with unlimited permissions. For example, this is the default behaviour in Docker containers. It's recommended to create a non-root user and either bake it into the Docker image (examples given below) or run the process on this user's behalf by invoking the container with the flag "-u username"

Otherwise: An attacker who manages to run a script on the server gets unlimited power over the local machine (e.g. change iptable and re-route traffic to their server)

6.14. Limit payload size using a reverse-proxy or a middleware

TL;DR: The bigger the body payload is, the harder your single thread works in processing it. This is an opportunity for attackers to bring servers to their knees without tremendous amount of requests (DOS/DDOS attacks). Mitigate this limiting the body size of incoming requests on the edge (e.g. firewall, ELB) or by configuring express body parser to accept only small-size payloads

Otherwise: Your application will have to deal with large requests, unable to process the other important work it has to accomplish, leading to performance implications and vulnerability towards DOS attacks

🔗 Read More: Limit payload size

6.15. Avoid JavaScript eval statements

TL;DR: eval is evil as it allows executing custom JavaScript code during run time. This is not just a performance concern but also an important security concern due to malicious JavaScript code that may be sourced from user input. Another language feature that should be avoided is new Function constructor. setTimeout and setInterval should never be passed dynamic JavaScript code either.

Otherwise: Malicious JavaScript code finds a way into text passed into eval or other real-time evaluating JavaScript language functions, and will gain complete access to JavaScript permissions on the page. This vulnerability is often manifested as an XSS attack.

6.16. Prevent evil RegEx from overloading your single thread execution

TL;DR: Regular Expressions, while being handy, pose a real threat to JavaScript applications at large, and the Node.js platform in particular. A user input for text to match might require an outstanding amount of CPU cycles to process. RegEx processing might be inefficient to an extent that a single request that validates 10 words can block the entire event loop for 6 seconds and set the CPU on 🔥. For that reason, prefer third-party validation packages like validator.js instead of writing your own Regex patterns, or make use of safe-regex to detect vulnerable regex patterns

Otherwise: Poorly written regexes could be susceptible to Regular Expression DoS attacks that will block the event loop completely. For example, the popular moment package was found vulnerable with malicious RegEx usage in November of 2017

6.17. Avoid module loading using a variable

TL;DR: Avoid requiring/importing another file with a path that was given as parameter due to the concern that it could have originated from user input. This rule can be extended for accessing files in general (i.e. fs.readFile()) or other sensitive resource access with dynamic variables originating from user input. Eslint-plugin-security linter can catch such patterns and warn early enough

Otherwise: Malicious user input could find its way to a parameter that is used to require tampered files, for example, a previously uploaded file on the file system, or access already existing system files.

🔗 Read More: Safe module loading

6.18. Run unsafe code in a sandbox

TL;DR: When tasked to run external code that is given at run-time (e.g. plugin), use any sort of 'sandbox' execution environment that isolates and guards the main code against the plugin. This can be achieved using a dedicated process (e.g. cluster.fork()), serverless environment or dedicated npm packages that act as a sandbox

Otherwise: A plugin can attack through an endless variety of options like infinite loops, memory overloading, and access to sensitive process environment variables

6.19. Take extra care when working with child processes

TL;DR: Avoid using child processes when possible and validate and sanitize input to mitigate shell injection attacks if you still have to. Prefer using child_process.execFile which by definition will only execute a single command with a set of attributes and will not allow shell parameter expansion.

Otherwise: Naive use of child processes could result in remote command execution or shell injection attacks due to malicious user input passed to an unsanitized system command.

6.20. Hide error details from clients

TL;DR: An integrated express error handler hides the error details by default. However, great are the chances that you implement your own error handling logic with custom Error objects (considered by many as a best practice). If you do so, ensure not to return the entire Error object to the client, which might contain some sensitive application details

Otherwise: Sensitive application details such as server file paths, third party modules in use, and other internal workflows of the application which could be exploited by an attacker, could be leaked from information found in a stack trace

6.21. Configure 2FA for npm or Yarn

TL;DR: Any step in the development chain should be protected with MFA (multi-factor authentication), npm/Yarn are a sweet opportunity for attackers who can get their hands on some developer's password. Using developer credentials, attackers can inject malicious code into libraries that are widely installed across projects and services. Maybe even across the web if published in public. Enabling 2-factor-authentication in npm leaves almost zero chances for attackers to alter your package code.

Otherwise: Have you heard about the eslint developer whose password was hijacked?

6.22. Modify session middleware settings

TL;DR: Each web framework and technology has its known weaknesses - telling an attacker which web framework we use is a great help for them. Using the default settings for session middlewares can expose your app to module- and framework-specific hijacking attacks in a similar way to the X-Powered-By header. Try hiding anything that identifies and reveals your tech stack (E.g. Node.js, express)

Otherwise: Cookies could be sent over insecure connections, and an attacker might use session identification to identify the underlying framework of the web application, as well as module-specific vulnerabilities

6.23. Avoid DOS attacks by explicitly setting when a process should crash

TL;DR: The Node process will crash when errors are not handled. Many best practices even recommend to exit even though an error was caught and got handled. Express, for example, will crash on any asynchronous error - unless you wrap routes with a catch clause. This opens a very sweet attack spot for attackers who recognize what input makes the process crash and repeatedly send the same request. There's no instant remedy for this but a few techniques can mitigate the pain: Alert with critical severity anytime a process crashes due to an unhandled error, validate the input and avoid crashing the process due to invalid user input, wrap all routes with a catch and consider not to crash when an error originated within a request (as opposed to what happens globally)

Otherwise: This is just an educated guess: given many Node.js applications, if we try passing an empty JSON body to all POST requests - a handful of applications will crash. At that point, we can just repeat sending the same request to take down the applications with ease

6.24. Prevent unsafe redirects

TL;DR: Redirects that do not validate user input can enable attackers to launch phishing scams, steal user credentials, and perform other malicious actions.

Otherwise: If an attacker discovers that you are not validating external, user-supplied input, they may exploit this vulnerability by posting specially-crafted links on forums, social media, and other public places to get users to click it.

6.25. Avoid publishing secrets to the npm registry

TL;DR: Precautions should be taken to avoid the risk of accidentally publishing secrets to public npm registries. An .npmignore file can be used to ignore specific files or folders, or the files array in package.json can act as an allow list.

Otherwise: Your project's API keys, passwords or other secrets are open to be abused by anyone who comes across them, which may result in financial loss, impersonation, and other risks.

6.26 Inspect for outdated packages

TL;DR: Use your preferred tool (e.g. npm outdated or npm-check-updates) to detect installed outdated packages, inject this check into your CI pipeline and even make a build fail in a severe scenario. For example, a severe scenario might be when an installed package is 5 patch commits behind (e.g. local version is 1.3.1 and repository version is 1.3.8) or it is tagged as deprecated by its author - kill the build and prevent deploying this version

Otherwise: Your production will run packages that have been explicitly tagged by their author as risky

6.27. Import built-in modules using the 'node:' protocol

`🌟 #new`

TL;DR: Import or require built-in Node.js modules using the 'node protocol' syntax:

import { functionName } from "node:module"; // note that 'node:' prefix

For example:

import { createServer } from "node:http";

This style ensures that there is no ambiguity with global npm packages and makes it clear for the reader that the code refers to a well-trusted official module. This style can be enforced with the eslint rule 'prefer-node-protocol'

Otherwise: Using the import syntax without 'node:' prefix opens the door for typosquatting attacks where one could mistakenly mistype a module name (e.g., 'event' instead of 'events) and get a malicious package that was built only to trick users into installing them

⬆ Return to top

`7. Draft: Performance Best Practices`

Our contributors are working on this section. Would you like to join?

7.1. Don't block the event loop

TL;DR: Avoid CPU intensive tasks as they will block the mostly single-threaded Event Loop and offload those to a dedicated thread, process or even a different technology based on the context.

Otherwise: As the Event Loop is blocked, Node.js will be unable to handle other request thus causing delays for concurrent users. 3000 users are waiting for a response, the content is ready to be served, but one single request blocks the server from dispatching the results back

7.2. Prefer native JS methods over user-land utils like Lodash

TL;DR: It's often more penalising to use utility libraries like lodash and underscore over native methods as it leads to unneeded dependencies and slower performance. Bear in mind that with the introduction of the new V8 engine alongside the new ES standards, native methods were improved in such a way that it's now about 50% more performant than utility libraries.

Otherwise: You'll have to maintain less performant projects where you could have simply used what was already available or dealt with a few more lines in exchange of a few more files.

⬆ Return to top

`8. Docker Best Practices`

🏅 Many thanks to Bret Fisher from whom we learned many of the following practices

8.1 Use multi-stage builds for leaner and more secure Docker images

TL;DR: Use multi-stage build to copy only necessary production artifacts. A lot of build-time dependencies and files are not needed for running your application. With multi-stage builds these resources can be used during build while the runtime environment contains only what's necessary. Multi-stage builds are an easy way to get rid of overweight and security threats.

Otherwise: Larger images will take longer to build and ship, build-only tools might contain vulnerabilities and secrets only meant for the build phase might be leaked.

Example Dockerfile for multi-stage builds

FROM node:14.4.0 AS build

COPY . .
RUN npm ci && npm run build


FROM node:slim-14.4.0

USER node
EXPOSE 8080

COPY --from=build /home/node/app/dist /home/node/app/package.json /home/node/app/package-lock.json ./
RUN npm ci --production

CMD [ "node", "dist/app.js" ]

🔗 Read More: Use multi-stage builds

8.2. Bootstrap using `node` command, avoid `npm start`

TL;DR: Use CMD ['node','server.js'] to start your app, avoid using npm scripts which don't pass OS signals to the code. This prevents problems with child-processes, signal handling, graceful shutdown and having zombie processes

Update: Starting from npm 7, npm claim to pass signals. We follow and will update accordingly

Otherwise: When no signals are passed, your code will never be notified about shutdowns. Without this, it will lose its chance to close properly possibly losing current requests and/or data

8.3. Let the Docker runtime handle replication and uptime

TL;DR: When using a Docker run time orchestrator (e.g., Kubernetes), invoke the Node.js process directly without intermediate process managers or custom code that replicate the process (e.g. PM2, Cluster module). The runtime platform has the highest amount of data and visibility for making placement decision - It knows best how many processes are needed, how to spread them and what to do in case of crashes

Otherwise: Container keeps crashing due to lack of resources will get restarted indefinitely by the process manager. Should Kubernetes be aware of that, it could relocate it to a different roomy instance

8.4. Use .dockerignore to prevent leaking secrets

TL;DR: Include a .dockerignore file that filters out common secret files and development artifacts. By doing so, you might prevent secrets from leaking into the image. As a bonus the build time will significantly decrease. Also, ensure not to copy all files recursively rather explicitly choose what should be copied to Docker

Otherwise: Common personal secret files like .env, .aws and .npmrc will be shared with anybody with access to the image (e.g. Docker repository)

🔗 Read More: Use .dockerignore

8.5. Clean-up dependencies before production

TL;DR: Although Dev-Dependencies are sometimes needed during the build and test life-cycle, eventually the image that is shipped to production should be minimal and clean from development dependencies. Doing so guarantees that only necessary code is shipped and the amount of potential attacks (i.e. attack surface) is minimized. When using multi-stage build (see dedicated bullet) this can be achieved by installing all dependencies first and finally running npm ci --production

Otherwise: Many of the infamous npm security breaches were found within development packages (e.g. eslint-scope)

🔗 Read More: Remove development dependencies

8.6. Shutdown smartly and gracefully

TL;DR: Handle the process SIGTERM event and clean-up all existing connection and resources. This should be done while responding to ongoing requests. In Dockerized runtimes, shutting down containers is not a rare event, rather a frequent occurrence that happen as part of routine work. Achieving this demands some thoughtful code to orchestrate several moving parts: The load balancer, keep-alive connections, the HTTP server and other resources

Otherwise: Dying immediately means not responding to thousands of disappointed users

🔗 Read More: Graceful shutdown

8.7. Set memory limits using both Docker and v8

TL;DR: Always configure a memory limit using both Docker and the JavaScript runtime flags. The Docker limit is needed to make thoughtful container placement decision, the --v8's flag max-old-space is needed to kick off the GC on time and prevent under utilization of memory. Practically, set the v8's old space memory to be a just bit less than the container limit

Otherwise: The docker definition is needed to perform thoughtful scaling decision and prevent starving other citizens. Without also defining the v8's limits, it will under utilize the container resources - Without explicit instructions it crashes when utilizing ~50-60% of its host resources

8.8. Plan for efficient caching

TL;DR: Rebuilding a whole docker image from cache can be nearly instantaneous if done correctly. The less updated instructions should be at the top of your Dockerfile and the ones constantly changing (like app code) should be at the bottom.

Otherwise: Docker build will be very long and consume lot of resources even when making tiny changes

8.9. Use explicit image reference, avoid `latest` tag

TL;DR: Specify an explicit image digest or versioned label, never refer to latest. Developers are often led to believe that specifying the latest tag will provide them with the most recent image in the repository however this is not the case. Using a digest guarantees that every instance of the service is running exactly the same code.

In addition, referring to an image tag means that the base image is subject to change, as image tags cannot be relied upon for a deterministic install. Instead, if a deterministic install is expected, a SHA256 digest can be used to reference an exact image.

Otherwise: A new version of a base image could be deployed into production with breaking changes, causing unintended application behaviour.

8.10. Prefer smaller Docker base images

TL;DR: Large images lead to higher exposure to vulnerabilities and increased resource consumption. Using leaner Docker images, such as Slim and Alpine Linux variants, mitigates this issue.

Otherwise: Building, pushing, and pulling images will take longer, unknown attack vectors can be used by malicious actors and more resources are consumed.

🔗 Read More: Prefer smaller images

8.11. Clean-out build-time secrets, avoid secrets in args

`🌟 #new`

TL;DR: Avoid secrets leaking from the Docker build environment. A Docker image is typically shared in multiple environment like CI and a registry that are not as sanitized as production. A typical example is an npm token which is usually passed to a dockerfile as argument. This token stays within the image long after it is needed and allows the attacker indefinite access to a private npm registry. This can be avoided by coping a secret file like .npmrc and then removing it using multi-stage build (beware, build history should be deleted as well) or by using Docker build-kit secret feature which leaves zero traces

Otherwise: Everyone with access to the CI and docker registry will also get access to some precious organization secrets as a bonus

8.12. Scan images for multi layers of vulnerabilities

TL;DR: Besides checking code dependencies vulnerabilities also scan the final image that is shipped to production. Docker image scanners check the code dependencies but also the OS binaries. This E2E security scan covers more ground and verifies that no bad guy injected bad things during the build. Consequently, it is recommended running this as the last step before deployment. There are a handful of free and commercial scanners that also provide CI/CD plugins

Otherwise: Your code might be entirely free from vulnerabilities. However it might still get hacked due to vulnerable version of OS-level binaries (e.g. OpenSSL, TarBall) that are commonly being used by applications

8.13 Clean NODE_MODULE cache

TL;DR: After installing dependencies in a container remove the local cache. It doesn't make any sense to duplicate the dependencies for faster future installs since there won't be any further installs - A Docker image is immutable. Using a single line of code tens of MB (typically 10-50% of the image size) are shaved off

Otherwise: The image that will get shipped to production will weigh 30% more due to files that will never get used

8.14. Generic Docker practices

TL;DR: This is a collection of Docker advice that is not related directly to Node.js - the Node implementation is not much different than any other language. Click read more to skim through.

8.15. Lint your Dockerfile

`🌟 #new`

TL;DR: Linting your Dockerfile is an important step to identify issues in your Dockerfile which differ from best practices. By checking for potential flaws using a specialised Docker linter, performance and security improvements can be easily identified, saving countless hours of wasted time or security issues in production code.

Otherwise: Mistakenly the Dockerfile creator left Root as the production user, and also used an image from unknown source repository. This could be avoided with with just a simple linter.

🔗 Read More: Lint your Dockerfile

⬆ Return to top

Milestones

To maintain this guide and keep it up to date, we are constantly updating and improving the guidelines and best practices with the help of the community. You can follow our milestones and join the working groups if you want to contribute to this project

Translations

All translations are contributed by the community. We will be happy to get any help with either completed, ongoing or new translations!

Completed translations

Brazilian Portuguese - Courtesy of Marcelo Melo
Chinese - Courtesy of Matt Jin
Russian - Courtesy of Alex Ivanov
Polish - Courtesy of Michal Biesiada
Japanese - Courtesy of Yuki Ota, Yuta Azumi
Basque - Courtesy of Ane Diaz de Tuesta & Joxefe Diaz de Tuesta

Translations in progress

French (Discussion)
Hebrew (Discussion)
Korean - Courtesy of Sangbeom Han (Discussion)
Spanish (Discussion)
Turkish (Discussion)

Steering Committee

Meet the steering committee members - the people who work together to provide guidance and future direction to the project. In addition, each member of the committee leads a project tracked under our GitHub projects.

Yoni Goldberg

Independent Node.js consultant who works with customers in the USA, Europe, and Israel on building large-scale Node.js applications. Many of the best practices above were first published at goldbergyoni.com. Reach Yoni at @goldbergyoni or me@goldbergyoni.com

Josh Hemphill

Full Stack Software Engineer / Developer specializing in Security, DevOps/DevSecOps, and ERP Integrations.

Raz Luvaton

Full Stack Developer who knows how to exit from Vim and loves Architecture, Virtualization and Security.

Contributing

If you've ever wanted to contribute to open source, now is your chance! See the contributing docs for more information.

Contributors ✨

Thanks goes to these wonderful people who have contributed to this repository!

_{Kevin Rambaud} 🖋	_{Michael Fine} 🖋	_{Shreya Dahal} 🖋	_{Matheus Cruz Rocha} 🖋	_{Yog Mehta} 🖋	_{Kudakwashe Paradzayi} 🖋	_t1st3 🖋
_{mulijordan1976} 🖋	_{Matan Kushner} 🖋	_{Fabio Hiroki} 🖋	_{James Sumners} 🖋	_{Dan Gamble} 🖋	_{PJ Trainor} 🖋	_{Remek Ambroziak} 🖋
_{Yoni Jah} 🖋	_{Misha Khokhlov} 🖋	_{Evgeny Orekhov} 🖋	_- 🖋	_{Isaac Halvorson} 🖋	_{Vedran Karačić} 🖋	_lallenlowe 🖋
_{Nathan Wells} 🖋	_{Paulo Reis} 🖋	_syzer 🖋	_{David Sancho} 🖋	_{Robert Manolea} 🖋	_{Xavier Ho} 🖋	_Aaron 🖋
_{Jan Charles Maghirang Adona} 🖋	_Allen 🖋	_{Leonardo Villela} 🖋	_{Michał Załęcki} 🖋	_{Chris Nicola} 🖋	_{Alejandro Corredor} 🖋	_cwar 🖋
_Yuwei 🖋	_{Utkarsh Bhatt} 🖋	_{Duarte Mendes} 🖋	_{Jason Kim} 🖋	_{Mitja O.} 🖋	_{Sandro Miguel Marques} 🖋	_Gabe 🖋
_{Ron Gross} 🖋	_{Valeri Karpov} 🖋	_{Sergio Bernal} 🖋	_{Nikola Telkedzhiev} 🖋	_{Vitor Godoy} 🖋	_{Manish Saraan} 🖋	_{Sangbeom Han} 🖋
_blackmatch 🖋	_{Joe Reeve} 🖋	_{Ryan Busby} 🖋	_{Iman Mohamadi} 🖋	_{Sergii Paryzhskyi} 🖋	_{Kapil Patel} 🖋	_迷渡 🖋
_Hozefa 🖋	_Ethan 🖋	_Sam 🖋	_Arlind 🖋	_{Teddy Toussaint} 🖋	_Lewis 🖋	_{Gabriel Lidenor} 🖋
_Roman 🖋	_Francozeira 🖋	_Invvard 🖋	_{Rômulo Garofalo} 🖋	_{Tho Q Luong} 🖋	_{Burak Shen} 🖋	_{Martin Muzatko} 🖋
_{Jared Collier} 🖋	_{Hilton Meyer} 🖋	_{ChangJoo Park(박창주)} 🖋	_{Masahiro Sakaguchi} 🖋	_{Keith Holliday} 🖋	_coreyc 🖋	_{Maximilian Berkmann} 🖋
_{Douglas Mariano Valero} 🖋	_{Marcelo Melo} 🖋	_{Mehmet Perk} 🖋	_{ryan ouyang} 🖋	_Shabeer 🖋	_{Eduard Kyvenko} 🖋	_{Deyvison Rocha} 🖋
_{George Mamer} 🖋	_{Konstantinos Leimonis} 🖋	_{Oliver Lluberes} 🌍	_{Tien Do} 🖋	_{Ranvir Singh} 🖋	_{Vadim Nicolaev} 🖋 🌍	_{German Gamboa Gonzalez} 🖋
_Hafez 🖋	_Chandiran 🖋	_{VinayaSathyanarayana} 🖋	_{Kim Kern} 🖋	_{Kenneth Freitas} 🖋	_songe 🖋	_{Kirill Shekhovtsov} 🖋
_Serge 🖋	_keyrwinz 🖋	_{Dmitry Nikitenko} 🖋	_bushuai 👀 🖋	_{Benjamin Gruenbaum} 🖋	_Ezequiel 🌍	_{Juan José Rodríguez} 🌍
_{Or Bin} 🖋	_{Andreo Vieira} 🖋	_{Michael Solomon} 🖋	_{Jimmy Callin} 🖋	_Siddharth 🖋	_{Ryan Smith} 🖋	_{Tom Boettger} 🖋
_{Joaquín Ormaechea} 🌍	_dfrzuz 🌍	_{Victor Homyakov} 🖋	_Josh 🖋 🛡️	_{Alec Francis} 🖋	_arjun6610 🖋	_{Jan Osch} 🖋
_{Thiago Rotondo Sampaio} 🌍	_Alexsey 🖋	_{Luis A. Acurero} 🌍	_{Lucas Romano} 🌍	_{Denise Case} 🖋	_{Nick Ribal} 🖋 👀	_0xflotus 🖋
_{Jonathan Chen} 🖋	_{Dilan Srilal} 🖋	_{vladthelittleone} 🌍	_{Nik Osvalds} 🖋	_{Daniel Kiss} 📖	_Forresst 🖋	_{Jonathan Svenheden} 🖋
_AustrisC 🖋	_{kyeongtae kim} 🌍	₀₀₇ 🖋	_{Ane Diaz de Tuesta} 🌍 🖋	_YukiOta 🌍	_{Frazer Smith} 🖋	_{Raz Luvaton} 🖋
_{Yuta Azumi} 🖋	_{andrewjbarbour} 🖋	_mr 🖋	_Aleksandar 🖋	_Owl 🖋	_{Yedidya Schwartz} 🖋 💡	_ari 🖋
_{Thomas König} 🖋	_{Kalle Lämsä} 🖋	_Wyatt 🖋	_{KHADIR Tayeb} 🖋	_{Shankar Regmi} 🖋	_Shubham 🖋	_{Lucas Alves} 🖋
_Benjamin 🖋	_{Yeoh Joer} 🖋	_Miigon 🖋	_{Rostislav Bogorad} 🖋	_Flouse 🖋	_{Tarantini Pereira} 🖋	_{Kazuki Matsuo} 🖋
_{Adam Smith} 🖋	_{Dohyeon Ko} 🖋	_{Vladislav Legkov} 🖋	_{Kerollos Magdy} 🖋	_{Erez Lieberman} 🖋	_{Breno Macedo} 🖋	_{Fernando Flores} 🌍
_{Rafael Brito} 🌍	_{Emiliano Peralta} 🌍	_{Shin, SJ} 🖋	_{Benjamin Forster} 🖋	_{Daniele Fedeli} 🖋	_djob195 🖋	_antspk 🖋
_정진영 🖋	_kkk-cashwalk 🖋	_{apainintheneck} 🖋	_{Fajar Budhi Iswanda} 🖋	_이주호 🖋	_Singh 🖋	_{Alex Dumitru} 🖋
_{Anton Lykhatskyi} 🖋	_sangwonlee 🖋	_{Eugenio Berretta} 🖋	_soranakk 🖋	_고준영 🖋 💻	_{Guilherme Portella} 🖋	_{André Esser} 🖋
_Scc 🌍	_{Mauro Accornero} 🖋	_no-yan 🖋	_hodbauer 🌍

Steering Committee Emeriti

Bruno Scheufler

💻 full-stack web engineer, Node.js & GraphQL enthusiast

Kyle Martin

Full Stack Developer & Site Reliability Engineer based in New Zealand, interested in web application security, and architecting and building Node.js applications to perform at global scale.

Kevyn Bruyere

Independent full-stack developer with a taste for Ops and automation.

Sagir Khan

Deep specialist in JavaScript and its ecosystem — React, Node.js, TypeScript, GraphQL, MongoDB, pretty much anything that involves JS/JSON in any layer of the system — building products using the web platform for the world’s most recognized brands. Individual Member of the Node.js Foundation.

Gar-b-age/CookLikeHOC

🥢像老乡鸡🐔那样做饭。已添加2026年发布的《老乡鸡菜品溯源报告 2.0中新出现的菜品。主要部分于2024年完工，非老乡鸡官方仓库。文字来自《老乡鸡菜品溯源报告》，并做归纳、编辑与整理。CookLikeHOC.

Docker Support | Development

像老乡鸡那样做饭

新更新

已添加2026年发布的《老乡鸡菜品溯源报告 2.0》中新出现的菜品。

一些说明

仓库主体部分于2024年完工，和2025年9月份的舆论事件无关。截止提交时，仓库的贡献者们与老乡鸡的唯一关系只有消费者和商家的关系。本仓库不是老乡鸡的官方仓库。如果有任何问题或意见建议，欢迎指出

现在

欢迎大家来贡献实拍图
现已上线网页端，点击访问
Run with Docker? Check it out here, supported by @honestAnt in PR #141
AI 绘制的手绘图版及AI配图流程版网页：点击访问, 手绘图由 @liucongg 贡献，见 PR #143

《老乡鸡菜品溯源报告》中公布的所有菜品已经全部录入完，欢迎大家查阅和补充。

文字超大段copy自《老乡鸡菜品溯源报告》，有编辑与整理

指路隔壁 How To Cook

至于为什么仓库名要叫CookLikeHOC，因为直接写Laoxiangji大概不方便阅读，而Home Original Chicken是china daily报道中所使用的老乡鸡的英文名，故简写成HOC。

Contributor

Logo

Star History

piyushsachdeva/CKA-2024

This repository contains the notes and code snippets of the CKA 2025 YouTube Playlist. The content is based on the latest 2025 curriculum and includes hands-on demos, assignments, and exam-based scenarios. I will be covering everything from the basics to the advanced level.

Certified Kubernetes Administrator(CKA) 20245

This is the GitHub repository to host all the notes, diagrams, assignments, and resources from the CKA course published on YouTube.

Note: If you found the content helpful, consider giving the repository a star ⭐

Checkout this file for the #40daysofkubernetes challenge details

🔗 Join our community 👇

🏆 #40daysofkubernetes Challenge - COMPLETED!

The #40daysofkubernetes challenge has been successfully completed! 🎉

Congratulations to all the amazing participants who dedicated their time and effort to learn Kubernetes throughout this journey.

🥇 Challenge Winners

🖊️ Blogging Champions

Shivam Gautam
Rahul Vadakkiniyil
Shriram Sahu
Teddy D
Pratik Shinde
Baivab Mukhopadhyay

👥 Community Champions

Baivab Mukhopadhyay - Discord: itzmario7320
Priyanka
Vivek
Dheeman Das
Micheal Choudhary

A huge thanks to everyone who participated, shared their learning journey, and contributed to building this amazing community! 🙏

Day0: Intro to the series

Course Introduction
Discord community server for assistance
Live QnA sessions every weekend
#40daysofkubernetes challenge

Day 1: Docker Fundamentals

Status: Video is live, check out 👉 Day1 👈 folder for notes and useful links ✅

What is Docker?
How is it different from Virtual Machines
Docker Architecture
Docker flow
Docker commands

Day 2 Video: Dockerize an application

Status: Video is live, check out 👉 Day2 👈 folder for notes and useful links ✅

What is Dockerfile, and how do you write it?
docker pull , push, tag etc

Day3 Video: Docker Multi-Stage Builds

Status: Video is live, check out 👉 Day3 👈 folder for notes and useful links ✅

How to write a dockerfile for multistage build
Benefits of multi-stage builds
Other docker best practices

Day 4 Video: Why do We need Kubernetes?

Status: Video is live, check out 👉 Day4 👈 folder for notes and useful links ✅

Day 5 Video: Kubernetes Architecture

Status: Video is live, check out 👉 Day5 👈 folder for notes and useful links ✅

Control plane VS Worker Nodes
Overview of control plane components

Day 6 Video: Install Kubernetes Cluster locally

Status: Video is live, check out 👉 Day6 👈 folder for notes and useful links ✅

Install Kind cluster locally
How to access the cluster

Day7 Video: Pods in Kubernetes

Status: Video is live, check out 👉 Day7 👈 folder for notes and useful links ✅

What are pods in Kubernetes?
Containers VS Pods
Imperative VS Declarative way for creating Kubernetes resources
Create a sample pod using the imperative way
Create a sample pod using the declarative way
Inspect the pods

Day8 Video: Replicasets and Deployments in Kubernetes:

Status: Video is live, check out 👉 Day8 👈 folder for notes and useful links ✅

Replication Controller
ReplicaSet
Deployments
How to perform Rolling updates/rollback
Scale the deployment

Day9 Video: Services in Kubernetes:

Status: Video is live, check out 👉 Day9 👈 folder for notes and useful links ✅

What are services in Kubernetes, and why do we need them?
Node port, ClusterIP, and LoadBalancer

Day 10 Video: Namespaces:

Status: Video is live, check out 👉 Day10 👈 folder for notes and useful links ✅

NameSpaces
Services and namespaces

Day 11 Video: Multi-container Pods

Status: Video is live, check out 👉 Day11 👈 folder for notes and useful links ✅

What are multi-container pods
Multi-container pods pattern - sidecar/init etc
Environment variables in Kubernetes

Day 12 Video: Daemonset, Cronjob, and job

Status: Video is live, check out 👉 Day12 👈 folder for notes and useful links ✅

What are Daemonset, cronjobs and Jobs
Cron fundamentals with examples

Day13 Video: Static Pods

Status: Video is live, check out 👉 Day13 👈 folder for notes and useful links ✅

What are static pods
Labels and selectors
Manual Scheduling

Day14 Video: Taints and Tolerations

Status: Video is live, check out 👉 Day14 👈 folder for notes and useful links ✅

Day15 Video: Node Affinity

Status: Video is live, check out 👉 Day15 👈 folder for notes and useful links ✅

Day16 Video: Resource Requests and Limits

Status: Video is live, check out 👉 Day16 👈 folder for notes and useful links ✅

Day17 Video: Autoscaling in Kubernetes

Status: Video is live, check out 👉 Day17 👈 folder for notes and useful links ✅

Horizontal VS Vertical Autoscaling
HPA, VPA, Cluster autoscaling, NAP
Metrics server

Day18 Video: Probes in Kubernetes

Status: Video is live, check out 👉 Day18 👈 folder for notes and useful links ✅

Liveness VS Readiness Probes
HTTP/TCP/Command-based health checks

Day19 Video: Config maps and Secrets

Status: Video is live, check out 👉 Day19 👈 folder for notes and useful links ✅

concept and demo

Day 20 Video: How SSL/TLS works

Status: Video is live, check out 👉 Day20 👈 folder for notes and useful links ✅

Symmetric VS Asymmetric encryption
SSL certificates and Certificate Authority

Day 21 Video: TLS in Kubernetes

Status: Video is live, check out 👉 Day21 👈 folder for notes and useful links ✅

How TLS works in Kubernetes
Why we need TLS in Kubernetes
Private key and public certificates

Day 22 Video: Authorization in Kubernetes

Status: Video is live, check out 👉 Day22 👈 folder for notes and useful links ✅

Authorization VS Authentication
Authorization types, ABAC, RBAC, Node, Webhook
Kubeconfig

Day 23 Video: Role-based access control (RBAC)

Status: Video is live, check out 👉 Day23 👈 folder for notes and useful links ✅

Role and role binding
Generate and approve the certificate
grant access to the user

Day 24 Video: Cluster role and cluster role binding

Status: Video is live, check out 👉 Day24 👈 folder for notes and useful links ✅

concept and demo

Day 25 Video: Service Account

Status: Video is live, check out 👉 Day25 👈 folder for notes and useful links ✅

What are service accounts, and why do we use them?
Create a service account and grant access to it

Day26 Video: Network Policies

Status: Video is live, check out 👉 Day26 👈 folder for notes and useful links ✅

Network policy concept
CNI installation
enforce network policy by creating the object

Day27 Video: Use Kubeadm to install a Kubernetes cluster

Status: Video is live, check out 👉 Day27 👈 folder for notes and useful links ✅

Provision underlying infrastructure to deploy a Kubernetes cluster
Setup Master Node to deploy Kubernetes components
Setup multiple worker nodes and join the master node

Day28 Video: Docker storage fundamentals

Status: Video is live, check out 👉 Day28 👈 folder for notes and useful links ✅

Why do we need storage in docker containers
persistent docker storage

Day29 Video: Storage in Kubernetes

How storage works in Kubernetes
hostpath volumes in Kubernetes
Persistent volumes and Persistent volume claims
Volume modes, Access modes, and reclaim policies for volumes
Storage classes and provisions

Day30 Video: How does DNS work?

What happens when you type a website address in your browser
different components involved in DNS
End-to-end flow
Important files and resources

Day31 Video: DNS in kubernetes

How DNS works in Kubernetes
Core-DNS

Day32 Video: Kubernetes Networking

CNI , Network Add-on
Containerd vs runc , container runtime

Day 33 Video: Ingress controller and Ingress resources

Day 34 Video: Perform a version upgrade on a Kubernetes cluster using Kubeadm

Day 35 Video: Implement etcd backup and restore

Day 36 Video: Monitoring, Logging and Alerting

Monitor Cluster components, Evaluate cluster and node logging
Understand how to monitor applications, metric server
Manage container stdout & stderr logs

Day 37 Video: Troubleshoot application failure

Day 38 Video: Troubleshoot cluster component failure

Day 39 Video: Network Troubleshooting

Worker node failure
cordon, uncordon and drain (maintenance)\

Day 40 Video: JSONPath, advance kubectl commands

JSON for beginners
JSON v/s YAML
JSONPATH basics
Multiple JSONPATH queries to fetch details

Day 41 Mission CKA

Exam Pattern
Pre-requisites
Last-minute preparation
Tips and Tricks
Sample questions

Day 42 Video: Realtime project: Host your own container registry on Kubernetes

This project will include multiple Kubernetes topics with real-time implementation.

Day 43 Video: Helm

Day 44 Video - Kustomize

Day 45 Video - StatefulSets

Day 46 Video - Priority class and preemption

Frequently asked questions:

I've been overwhelmed by the fantastic response to my new YouTube series on the Certified Kubernetes Administrator (CKA) exam! But with all the excitement came some questions, and I'm here to address them head-on.

1) 𝐈 𝐜𝐚𝐧𝐧𝐨𝐭 𝐚𝐟𝐟𝐨𝐫𝐝 𝐭𝐡𝐞 𝐂𝐊𝐀 𝐞𝐱𝐚𝐦 𝐢𝐭'𝐬 𝐭𝐨𝐨 𝐞𝐱𝐩𝐞𝐧𝐬𝐢𝐯𝐞. 𝐒𝐡𝐨𝐮𝐥𝐝 𝐈 𝐬𝐭𝐢𝐥𝐥 𝐟𝐨𝐥𝐥𝐨𝐰 𝐚𝐥𝐨𝐧𝐠?

The content of this playlist is based on the exam curriculum because it provides a well-organized learning path. You don't have to worry about the roadmap; you can focus on learning. Even if you are not taking the exam now, you are still gaining the hands-on knowledge that a Kubernetes administrator should have; that's good enough!

𝟐) 𝐖𝐡𝐚𝐭 𝐚𝐫𝐞 𝐭𝐡𝐞 𝐩𝐫𝐞𝐫𝐞𝐪𝐮𝐢𝐬𝐢𝐭𝐞𝐬 𝐟𝐨𝐫 𝐭𝐡𝐢𝐬 𝐜𝐨𝐮𝐫𝐬𝐞?

The only prerequisites are basic Linux understanding; all the other prerequisites are already covered in this series. Check out the GitHub repo below for the course content. Yes, it is absolutely free for anyone to join and follow along.

𝟑) 𝐖𝐡𝐢𝐜𝐡 𝐂𝐥𝐨𝐮𝐝 𝐩𝐫𝐨𝐯𝐢𝐝𝐞𝐫 𝐚𝐫𝐞 𝐰𝐞 𝐮𝐬𝐢𝐧𝐠 𝐟𝐨𝐫 𝐭𝐡𝐞 𝐝𝐞𝐦𝐨?

We will not be using any Cloud as the focus is on Kubernetes. Using a cloud service would mean the cloud provider manages the control plane, limiting learning. We will use a local Kubernetes installation on a Kind cluster and a Kubeadm installation on virtual machines.

𝟒) 𝐀𝐫𝐞 𝐰𝐞 𝐝𝐨𝐢𝐧𝐠 𝐚𝐧𝐲 𝐫𝐞𝐚𝐥-𝐭𝐢𝐦𝐞 𝐩𝐫𝐨𝐣𝐞𝐜𝐭𝐬 𝐢𝐧 𝐭𝐡𝐢𝐬 𝐬𝐞𝐫𝐢𝐞𝐬?

Yes, there will be a couple of real-time projects at the end of this series. We cannot do real-time full-fledged projects in Kubernetes without completing all the essential topics. That is why I added the projects at the end and hands-on tasks in almost every video.

5) 𝐇𝐨𝐰 𝐦𝐚𝐧𝐲 𝐯𝐢𝐝𝐞𝐨𝐬 𝐰𝐢𝐥𝐥 𝐛𝐞 𝐩𝐮𝐛𝐥𝐢𝐬𝐡𝐞𝐝 𝐞𝐯𝐞𝐫𝐲 𝐰𝐞𝐞𝐤?

I have finished recording the entire series and am editing the last few videos. I plan to publish 3 to 4 weekly videos every Monday through Thursday. I have chosen not to publish daily so that viewers following the series have time to understand the concepts, practice hands-on, document their learning, and not feel left behind.

6) 𝐖𝐡𝐚𝐭 𝐢𝐟 𝐰𝐞 𝐚𝐫𝐞 𝐬𝐭𝐮𝐜𝐤 𝐬𝐨𝐦𝐞𝐰𝐡𝐞𝐫𝐞 𝐚𝐧𝐝 𝐧𝐞𝐞𝐝 𝐚𝐬𝐬𝐢𝐬𝐭𝐚𝐧𝐜𝐞?

You can comment on the video by providing complete details about the issue/query, or you can open a new thread in the discord channel of help-cka-2024, and someone will help you. I also plan to host a live Q&A session every weekend.

render-examples/mysql

MySQL 8.0 and 5.7 on Render

MySQL on Render

This is a template repository for running MySQL on Render.

It uses the official MySQL Docker image.
Render Disks provide fast, persistent SSD storage for your database.
MySQL runs in your private network and isn't exposed to the public Internet.

MySQL Versions

The master branch runs MySQL 8. You can use the mysql-5 branch to run MySQL 5 instead.

Deployment

See https://render.com/docs/deploy-mysql.

autowarefoundation/autoware

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

Autoware is the world's leading open-source autonomous driving framework. Autoware provides a comprehensive, production-ready software stack designed to accelerate the commercial deployment of autonomous vehicles across diverse platforms and use cases.

🚀 Get Started

New to Autoware?

Install Autoware → Set up your environment and build the stack from source.

Run the Quick Start demo → Drive a simulated vehicle in just a few minutes.

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.

Contributing

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

solana-foundation/solana-verifiable-build

CLI tool for deterministically building and verifying executable against on-chain programs or buffer accounts

Solana Verified Builds

This repository demonstrates how to implement verified builds for Solana programs. Verified builds ensure that your deployed program matches exactly with your public source code, promoting transparency and security in the Solana ecosystem.

What are Verified Builds?

Verified builds allow developers and users to verify that a deployed Solana program matches its source code. This verification:

Ensures program authenticity
Promotes transparency
Builds user trust
Makes source code discoverable

Quick Start

Install prerequisites:
- Docker
- Cargo
- Solana Verify CLI (cargo install solana-verify --locked)

For production use, prefer installing from a tagged release.

Build your program:

solana-verify build

For programs that don't depend on solana-program (e.g. SDK v3 or pinocchio), add the Solana CLI version in your root Cargo.toml so the tool can pick the right build image:

[workspace.metadata.cli]
solana = "3.0.0"

The tool checks this first, then falls back to Cargo.lock (solana-program, solana-program-error, or solana-account-info).

Deploy and verify:

# Deploy
solana program deploy -u $NETWORK_URL target/deploy/$PROGRAM_LIB_NAME.so --program-id $PROGRAM_ID

# Verify against repository -> upload your build data on chain
solana-verify verify-from-repo -u $NETWORK_URL --program-id $PROGRAM_ID https://github.com/$REPO_PATH

# Trigger a remote job
solana-verify remote submit-job --program-id $PROGRAM_ID --uploader $THE_PUBKEY_THAT_UPLOADED_YOUR_BUILD_DATA

The legacy --remote flag on verify-from-repo has been deprecated. Upload your PDA with programs upgrade authority, then run the remote submit-job command to queue OtterSec's worker. For a full walkthrough of the PDA workflow, see the Solana verified builds guide.

Documentation

For detailed instructions and best practices, please refer to the official Solana documentation on verified builds.

Security Considerations

While verified builds enhance transparency, they should not be considered a complete security solution. Always:

Review the source code
Use trusted build environments
Consider using governance solutions for program upgrades

Current Verification Scope

Build images are selected by pinned digest.
Solana/Agave installer scripts in generated Dockerfiles are checksum pinned.
Post-install verification of installed toolchain/platform-tools is still follow-up work.

For responsible disclosure of bugs related to verified builds CLI, please email maintainers@ellipsislabs.xyz with a detailed description of the attack vector.

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Releasing

Use .github/workflows/release.yml (Release) as the canonical release path. Use .github/workflows/build.yml only for manual artifact builds from a specific ref.

See RELEASE.md for release steps and recovery procedures.

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

openai/codex-universal

Base docker image used in Codex environments

codex-universal

codex-universal is a reference implementation of the base Docker image available in OpenAI Codex.

This repository is intended to help developers cutomize environments in Codex, by providing a similar image that can be pulled and run locally. This is not an identical environment but should help for debugging and development.

For more details on environment setup, see OpenAI Codex.

Usage

The Docker image is available at:

docker pull ghcr.io/openai/codex-universal:latest

This repository builds the image for both linux/amd64 and linux/arm64. However we only run the linux/amd64 version. Your installed Docker may support linux/amd64 emulation by passing the --platform linux/amd64 flag.

The arm64 image differs from the amd64 image in 2 ways:

OpenJDK 10 is not available on amd64
The arm64 image skips installing swift because of a current bug with mise

The below script shows how can you approximate the setup environment in Codex:

# See below for environment variable options.
# This script mounts the current directory similar to how it would get cloned in.
docker run --rm -it \
    -e CODEX_ENV_PYTHON_VERSION=3.12 \
    -e CODEX_ENV_NODE_VERSION=20 \
    -e CODEX_ENV_RUST_VERSION=1.87.0 \
    -e CODEX_ENV_GO_VERSION=1.23.8 \
    -e CODEX_ENV_SWIFT_VERSION=6.2 \
    -e CODEX_ENV_RUBY_VERSION=3.4.4 \
    -e CODEX_ENV_PHP_VERSION=8.4 \
    -v $(pwd):/workspace/$(basename $(pwd)) -w /workspace/$(basename $(pwd)) \
    ghcr.io/openai/codex-universal:latest

codex-universal includes setup scripts that look for CODEX_ENV_* environment variables and configures the language version accordingly.

Configuring language runtimes

The following environment variables can be set to configure runtime installation. Note that a limited subset of versions are supported (indicated in the table below):

Environment variable	Description	Supported versions	Additional packages
`CODEX_ENV_PYTHON_VERSION`	Python version to install	`3.10`, `3.11.12`, `3.12`, `3.13`, `3.14.0`	`pyenv`, `poetry`, `uv`, `ruff`, `black`, `mypy`, `pyright`, `isort`
`CODEX_ENV_NODE_VERSION`	Node.js version to install	`18`, `20`, `22`	`corepack`, `yarn`, `pnpm`, `npm`
`CODEX_ENV_RUST_VERSION`	Rust version to install	`1.83.0`, `1.84.1`, `1.85.1`, `1.86.0`, `1.87.0`, `1.88.0`, `1.89.0`, `1.90`, `1.91.1`, `1.92.0`, `1.93.0`, `1.94.0`, `1.95.0`
`CODEX_ENV_GO_VERSION`	Go version to install	`1.22.12`, `1.23.8`, `1.24.3`, `1.25.1`
`CODEX_ENV_SWIFT_VERSION`	Swift version to install	`5.10`, `6.1`, `6.2`
`CODEX_ENV_RUBY_VERSION`	Ruby version to install	`3.2.3`, `3.3.8`, `3.4.4`
`CODEX_ENV_PHP_VERSION`	PHP version to install	`8.4`, `8.3`, `8.2`
`CODEX_ENV_JAVA_VERSION`	JDK version to install	`25`, `24`, `23`, `22`, `21`, `17`, `11`

What's included

In addition to the packages specified in the table above, the following packages are also installed:

bun: 1.2.10
bazelisk / bazel
erlang: 27.1.2
elixir: 1.18.3

See Dockerfile for the full details of installed packages.

Contributing

See CONTRIBUTING.md.

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 63 languages, 21 formats, 19 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.

📣 MegaLinter 9.5.0 is out! Discover the new features and security recommendations in the release announcement.

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	code-analyzer-flow SALESFORCE_CODE_ANALYZER_FLOW
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
ACTION	zizmor ACTION_ZIZMOR
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	betterleaks REPOSITORY_BETTERLEAKS
REPOSITORY	grype REPOSITORY_GRYPE
REPOSITORY	kics REPOSITORY_KICS	🚫
REPOSITORY	ls-lint REPOSITORY_LS_LINT
REPOSITORY	osv-scanner REPOSITORY_OSV_SCANNER
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 ?

Docker registry change (since v9.5.0): MegaLinter Docker images are published only to GitHub Container Registry (ghcr.io). The Docker Hub registry (docker.io/oxsecurity/megalinter, formerly oxsecurity/megalinter:*) is frozen at v9.4.0 until we implement OIDC-based publishing to Docker Hub. If you pull oxsecurity/megalinter:v9 from Docker Hub you will stay on v9.4.0. To get v9.5.0 and later, switch your image: / docker pull references to ghcr.io/oxsecurity/megalinter:v9 (same applies to :beta and all flavor tags like ghcr.io/oxsecurity/megalinter-python:v9). GitHub Action users (uses: oxsecurity/megalinter@v9) are not affected, as the action already pulls from ghcr.io.

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

Docker image: ghcr.io/oxsecurity/megalinter:v9
GitHub Action: oxsecurity/megalinter@v9

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

Docker image: ghcr.io/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

permissions: {}

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:
          # SECURITY NOTE: Using a Personal Access Token (PAT) is NOT
          # recommended. Open-source projects have been heavily targeted by
          # supply-chain attacks in recent months, and a leaked PAT can give
          # attackers broad write access to your repository: better safe
          # than sorry! If you only need workflows to re-trigger after
          # MegaLinter applies fixes, prefer one of these safer alternatives:
          #   - Manually re-run the workflow from the GitHub Actions tab, or
          #   - Push another commit on the branch to trigger workflows again.
          # Only define `secrets.PAT` if you fully understand the trade-off.
          token: ${{ secrets.PAT || secrets.GITHUB_TOKEN }}
          persist-credentials: false # Comment this line and uncomment the next one if you use APPLY_FIXES
          # persist-credentials: true # zizmor: ignore[artipacked]
          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@v8
        with:
          # SECURITY NOTE: see the warning on the checkout step above —
          # using `secrets.PAT` is NOT recommended for security reasons.
          # Prefer manually re-running the workflow or pushing another
          # commit on the branch to trigger workflows again.
          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')
        env:
          PR_NUMBER: ${{ steps.cpr.outputs.pull-request-number }}
          PR_URL: ${{ steps.cpr.outputs.pull-request-url }}
        run: |
          echo "Pull Request Number - ${PR_NUMBER}"
          echo "Pull Request URL - ${PR_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: ghcr.io/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 ghcr.io/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) \
            ghcr.io/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 ghcr.io/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) \
        ghcr.io/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.

Alternative: Azure DevOps Extension (Community)

Note: This is a community-maintained extension and is not affiliated with or maintained by the MegaLinter team.

As an alternative to the manual Docker configuration above, the community-maintained megalinter-ado Azure DevOps extension provides a native Azure Pipelines task for running MegaLinter.

Install from the Visual Studio Marketplace, then add the task to your pipeline:

- task: MegaLinter@1
  displayName: Run MegaLinter
  inputs:
    flavor: all
    fix: true
    createFixPR: true
  env:
    SYSTEM_ACCESSTOKEN: $(System.AccessToken)

See the extension repository for full configuration options.

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: ghcr.io/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 'ghcr.io/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!

PR Comment Reporting from Jenkins

When MegaLinter runs from a Jenkins Multibranch Pipeline, it can automatically post results as comments on pull requests / merge requests hosted on GitHub, GitLab, Azure DevOps, or Bitbucket.

MegaLinter auto-detects the git hosting platform by inspecting the GIT_URL environment variable (provided by Jenkins Git plugin). It then maps Jenkins environment variables (CHANGE_ID, GIT_COMMIT, BUILD_URL, etc.) to the native CI variables each comment reporter expects.

Requirements

Jenkins Multibranch Pipeline with the appropriate Branch Source plugin (GitHub Branch Source, GitLab Branch Source, or Bitbucket Branch Source)
The pipeline must be triggered by a pull request / merge request (so CHANGE_ID is set by Jenkins)
An authentication token for the target platform, stored as a Jenkins credential

Platform Configuration

Platform	Required Token Variable	Notes
GitHub	`GITHUB_TOKEN` (recommended) — `PAT` only if strictly required	Prefer `GITHUB_TOKEN`. Personal Access Tokens (PAT) are not recommended due to recent supply-chain attacks on open-source projects; a leaked PAT can give attackers broad write access to your repository. Token needs `repo` scope (or `issues:write` + `pull-requests:write` for fine-grained tokens).
GitLab	`GITLAB_ACCESS_TOKEN_MEGALINTER`	Personal access token with `api` scope
Azure DevOps	`SYSTEM_ACCESSTOKEN`	Personal access token with Code (Read & Write) permission
Bitbucket	`BITBUCKET_REPO_ACCESS_TOKEN`	Repository access token with Pull-requests: Write scope

Jenkinsfile Example with GitHub PR Comments

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

Self-hosted / On-premise Platforms

MegaLinter detects the platform by looking for keywords in the GIT_URL hostname (e.g., gitlab.mycompany.com is detected as GitLab, github.internal.corp.com as GitHub).

If your self-hosted instance uses a hostname without the platform name (e.g., git.mycompany.com), set the JENKINS_REPO_PLATFORM environment variable to explicitly tell MegaLinter which platform to use:

environment {
    JENKINS_REPO_PLATFORM = 'gitlab'  // or 'github', 'azure', 'bitbucket'
    GITLAB_ACCESS_TOKEN_MEGALINTER = credentials('gitlab-token')
}

Additional Variables

For most setups, MegaLinter derives all needed variables automatically. In rare cases, you may need to set additional platform-specific variables:

GitLab: Set CI_PROJECT_ID if the project path cannot be parsed from GIT_URL
Azure DevOps: Set SYSTEM_ACCESSTOKEN as a Jenkins credential

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: ghcr.io/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: ghcr.io/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 ghcr.io/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 ghcr.io/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 a linter is in both ENABLE_LINTERS and DISABLE_LINTERS, ENABLE_LINTERS wins by default. Set ENABLE_DISABLE_LINTERS_PRIORITY: DISABLE to make DISABLE_LINTERS override ENABLE_LINTERS instead (useful to trim an inherited ENABLE_LINTERS list when using EXTENDS).
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

Inherit a shared ENABLE_LINTERS list via EXTENDS but skip one of the inherited linters locally

EXTENDS: https://example.com/shared/.mega-linter.yml
ENABLE_DISABLE_LINTERS_PRIORITY: DISABLE
DISABLE_LINTERS:
  - PYTHON_PYLINT

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.

Security warning — Personal Access Tokens (PAT) are NOT recommended. Open-source projects have been heavily targeted by supply-chain attacks in recent months, and a leaked or compromised PAT can give attackers broad write access to your repository — better safe than sorry! Before adding a PAT secret, ask yourself if you really need workflows to re-trigger automatically after MegaLinter pushes a fix commit. In most cases the simpler and safer workaround is enough:

Manually re-run the failed workflow from the GitHub Actions tab, or

Push another commit on the branch (even an empty one: git commit --allow-empty -m "trigger CI") so GitHub re-runs the workflows.

Only set up a PAT if you fully understand the trade-off. If you do, use a fine-grained token scoped to a single repository with the minimum required permissions, and rotate it regularly.

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

Method 1: The most secured (still discouraged — read the warning above)
- 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 strongly discouraged — 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`)	`root`
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
SYSTEM_ACCESSTOKEN
(^|)(USERNAME)($|)
(^|)(PASSWORD|PASSWD|PASS|PWD)($|)
(^|)(TOKEN|ID_TOKEN|ACCESS_TOKEN|REFRESH_TOKEN|BEARER)($|)
(^|)(SECRET|SECRETS)($|)
(^|)(API_KEY|APP_KEY|CLIENT_ID|CLIENT_SECRET|CLIENT_KEY|SECRET_KEY|ACCESS_KEY|ACCESS_KEY_ID|PRIVATE_KEY|SSH_KEY|SIGNING_KEY|ENCRYPTION_KEY|LICENSE_KEY)($|)
(^|)(AUTH|AUTHORIZATION)($|)
(^|)(CERT|CERTIFICATE|CA_BUNDLE|KUBECONFIG)($|)
(^|)(CONNECTION_STRING|DATABASE_URL|DB_URL|DSN)($|)
(GOOGLE_APPLICATION_CREDENTIALS)
(GCP_SERVICE_ACCOUNT.*)
(SFDX_CLIENT_ID_.*)
(SFDX_CLIENT_KEY_.*)
(^|_)(SLACK|DISCORD|TEAMS|WEBHOOK)URL($|)

This compact list is intentionally pattern-based: variables such as GITHUB_TOKEN, CI_JOB_TOKEN, NPM_TOKEN, GIT_AUTHORIZATION_BEARER, AWS_SECRET_ACCESS_KEY, AZURE_CLIENT_SECRET, OPENAI_API_KEY, DOCKER_PASSWORD, and SMTP_PASSWORD are hidden through these broader matchers.

Security boundaries and threat model

When a linter or plugin command is executed, MegaLinter builds a child-process environment where matched sensitive variables are replaced with HIDDEN_BY_MEGALINTER.

This means:

The original value of a matched environment variable is not accessible from that environment variable entry in the child process.

This does not mean full sandboxing. A malicious dependency can still attempt to collect secrets from other channels, such as:

Unmatched variables (for example after custom overrides of SECURED_ENV_VARIABLES_DEFAULT)
Variables explicitly unhidden with (linter-key)_UNSECURED_ENV_VARIABLES
Files mounted in the workspace, command arguments, or generated config files
External credential sources (cloud metadata services, secret managers, network endpoints)

To maximize protection:

Keep SECURED_ENV_VARIABLES_DEFAULT unchanged when possible
Add your project-specific patterns with SECURED_ENV_VARIABLES
Minimize extra credentials exposed to the MegaLinter runtime

Example (compromised dependency scenario):

If a linter dependency (for example axios) is compromised and executes malicious code, it can read the environment passed to that linter process.
In that environment, matched variables are already replaced by HIDDEN_BY_MEGALINTER.
So reading GITHUB_TOKEN, NPM_TOKEN, OPENAI_API_KEY, or AWS_SECRET_ACCESS_KEY from the process environment returns HIDDEN_BY_MEGALINTER, not the original secret value.
The same attack could still try to obtain secrets from other channels listed above (files, arguments, external services, etc.).

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	125
c_cpp	Optimized for pure C/C++ projects	60
ci_light	Optimized for CI items (Dockerfile, Jenkinsfile, JSON/YAML schemas,XML	24
cupcake	MegaLinter for the most commonly used languages	92
documentation	MegaLinter for documentation projects	53
dotnet	Optimized for C, C++, C# or VB based projects	67
dotnetweb	Optimized for C, C++, C# or VB based projects with JS/TS	76
formatters	Contains only formatters	19
go	Optimized for GO based projects	55
java	Optimized for JAVA based projects	58
javascript	Optimized for JAVASCRIPT or TYPESCRIPT based projects	63
php	Optimized for PHP based projects	58
python	Optimized for PYTHON based projects	70
ruby	Optimized for RUBY based projects	54
rust	Optimized for RUST based projects	54
salesforce	Optimized for Salesforce based projects	58
security	Optimized for security	25
swift	Optimized for SWIFT based projects	54
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

Community Tools

Beyond plugins, the community has built additional tools that integrate with MegaLinter. These are independently maintained and not affiliated with the MegaLinter team.

Name	Description	Author
megalinter-mcp-server	An MCP server for running MegaLinter via mega-linter-runner. Provides 15 MCP tools for execution, discovery, and analysis. Works with GitHub Copilot Chat in VS Code and other MCP-compatible clients. Available on npm.	DownAtTheBottomOfTheMoleHole
megalinter-ado	Azure DevOps extension providing a native pipeline task for running MegaLinter. Supports flavor selection, auto-fix PRs, and PR comments. Available on the Visual Studio Marketplace.	DownAtTheBottomOfTheMoleHole

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

iggredible/Learn-Vim

Learning Vim and Vimscript doesn't have to be hard. This is the guide that you're looking for 📖

Learn Vim (the Smart Way)

What's This?

Learn Vim (the Smart Way) is a guide to learn the good parts of Vim.

There are many places to learn Vim: the vimtutor is a great place to start and the help manual has all the references you will ever need. However, the average user needs something more than vimtutor and less than the help manual. This guide attempts to bridge that gap by highlighting only the key features to learn the most useful parts of Vim in the least amount of time possible.

This guide is written for both beginner and advanced Vimmers. It starts out with broad and simple concepts and ends with specific and advanced concepts. If you're an advanced user already, I encourage you to read this guide from start to finish anyway, because you may learn something new!

Read Locally (with Docker)

You can read this book locally with Docker. Just run:

docker compose -f book/docker-compose.yml up --build

Then open http://localhost:8080.

I Want More Vim Tips!

Follow @learnvim for updates, Vim tips, etc.

Support This Project

This guide is and will always be free.

If you want to financially support this project, you can either purchase this guide on Leanpub or buy me a coffee!

Prologue

Ch 0 - Read This First

Part 1: Learn Vim the Smart Way

Part 2: Customize Vim the Smart Way

Part 3: Learn Vimscript the Smart Way

Translations

Learn-Vim 中文翻译(zh-CN)
Learn-Vim Spanish(es)

License & Copyright

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International.

GitHub Dockerfile Monthly Trending

freeCodeCamp/rdb-alpha

Prerequisites

How to Run a Project in Docker

How to Restart or Switch Projects

tutorial.json File URLs for CodeRoad

kagisearch/kagi-docs

Kagi Inc. Documentation

Contents

Knowledgebase Map

Support

Discussions

Community

Contributing

Issues

Pull Requests

Creating a Pull Request

Building

Development on your localhost

vulhub/vulhub

Quick Start

Troubleshooting

Contributing

Partners

License

redhat-openshift-ecosystem/community-operators-prod

Openshift Community Operators

About this repository

Add your Operator

Contributing Guide

IMPORTANT NOTICE

Reporting Bugs

yankils/Simple-DevOps-Project

Simple DevOps Project

Purpose:

redhat-openshift-ecosystem/certified-operators

Red Hat certified operators production catalog

Operator bundle submission

Pull request

Directory structure

Format of ci.yaml file

goldbergyoni/nodebestpractices

Node.js Best Practices

🎊 2026 edition is here!

Welcome! 3 Things You Ought To Know First

By Yoni Goldberg

Learn with me: As a consultant, I engage with worldwide teams on various activities like workshops and code reviews. 🎉AND... Hold on, I've just launched my beyond-the-basics testing course, which is on a 🎁 limited-time sale until August 7th

Table of Contents

1. Project Architecture Practices

1.1 Structure your solution by business components

📝 #updated

1.2 Layer your components with 3-tiers, keep the web layer within its boundaries

📝 #updated

1.3 Wrap common utilities as packages, consider publishing

1.4 Use environment aware, secure and hierarchical config

📝 #updated

1.5 Consider all the consequences when choosing the main framework

🌟 #new

1.6 Use TypeScript sparingly and thoughtfully

🌟 #new

2. Error Handling Practices

2.1 Use Async-Await or promises for async error handling

2.2 Extend the built-in Error object

📝 #updated

2.3 Distinguish catastrophic errors from operational errors

📝 #updated

2.4 Handle errors centrally, not within a middleware

2.5 Document API errors using OpenAPI or GraphQL

2.6 Exit the process gracefully when a stranger comes to town

2.7 Use a mature logger to increase errors visibility

📝 #updated

2.8 Test error flows using your favorite test framework

📝 #updated

2.9 Discover errors and downtime using APM products

2.10 Catch unhandled promise rejections

📝 #updated

2.11 Fail fast, validate arguments using a dedicated library

2.12 Always await promises before returning to avoid a partial stacktrace

🌟 #new

2.13 Subscribe to event emitters and streams 'error' event

`tutorial.json` File URLs for CodeRoad

`1. Project Architecture Practices`

`📝 #updated`

`📝 #updated`

`📝 #updated`

`🌟 #new`

`🌟 #new`

`2. Error Handling Practices`

`📝 #updated`

`📝 #updated`

`📝 #updated`

`📝 #updated`

`📝 #updated`

`🌟 #new`

`🌟 #new`

`3. Code Patterns And Style Practices`

`📝 #updated`

`📝 #updated`

3.10 Use the `===` operator

`🌟 #new`

`4. Testing And Overall Quality Practices`

`🌟 #new`

`🌟 #new`

`🌟 #new`

`🌟 #new`

`🌟 #new`

`🌟 #new`

`5. Going To Production Practices`

`📝 #updated`

5.15. Set `NODE_ENV=production`

`📝 #updated`

5.19. Install your packages with `npm ci`

`6. Security Best Practices`