Galaxio·Team
EN
GitHub
Galaxio Team / Est. 2018
System status — synchronized
v3.0 · ECMA / 2026
Open-source · Performance engineering

One ecosystem,many movingparts

We build plugins, a CLI, project templates and portable AI agent plugins for Gatling and adjacent performance-testing ecosystems.

Fourteen repositories. One ecosystem.

Gatling plugins, AI agent plugins, a CLI, project templates and a spec-driven methodology. Tap any repository to see real usage and open its README.

Gatling Plugins04

Published to Maven Central under org.galaxio
R / 01
gatling-kafka-pluginPlugin
Kafka protocol plugin — produce, request-reply, Avro.

// About

Kafka protocol plugin for Gatling. Produce-only and request-reply flows with plain serialization, Avro4s helpers and Schema Registry integration. Reply correlation is configured at the protocol level and tracked by a shared consumer.

// Highlights

  • Produce-only via kafka("name").topic(...).send(...)
  • Request-reply with matchByValue / matchByMessage correlation
  • Avro4s + Schema Registry, or your own Kafka Serde[T]
  • Gatling 3.13.5 · Scala 2.13.16 · Java 17+
scala · build.sbt + simulation
// build.sbt
libraryDependencies += "org.galaxio" %% "gatling-kafka-plugin" % "<version>" % Test

import org.galaxio.gatling.kafka.Predef._
import io.gatling.core.Predef._

val kafkaConf = kafka
  .properties(Map("bootstrap.servers" -> "localhost:9092"))

val scn = scenario("Kafka Producer")
  .exec(
    kafka("send message")
      .topic("test-topic")
      .send[String, String]("key", """{"msg": "hello"}""")
  )

setUp(scn.inject(atOnceUsers(1))).protocols(kafkaConf)

// About

Execute SQL queries, inserts, updates, batch operations, raw SQL and stored procedures against any JDBC-compatible database, with HikariCP connection pooling and result checks. Vendor drivers are not bundled — add the one for your database.

// Highlights

  • query / queryP prepared statements, insertInto, rawSql, batch, call
  • HikariCP pooling with a dedicated blocking executor
  • Checks: allResults, simpleCheck, Gatling EL in SQL
  • Gatling 3.13.x · Scala 2.13 · Java 11+
scala · build.sbt + simulation
// build.sbt — plugin + your JDBC driver
libraryDependencies ++= Seq(
  "org.galaxio" %% "gatling-jdbc-plugin" % "<version>" % Test,
  "org.postgresql" % "postgresql" % "42.7.11" % Test,
)

import org.galaxio.gatling.jdbc.Predef._

val dbConf = DB
  .url("jdbc:postgresql://localhost:5432/test")
  .username("test").password("test")
  .maximumPoolSize(10)

scenario("JDBC Query")
  .exec(
    jdbc("find user")
      .queryP("SELECT * FROM users WHERE id = {id}")
      .params("id" -> "#{userId}")
      .check(simpleCheck(_.nonEmpty))
  )

// About

AMQP protocol plugin supporting RabbitMQ with publish, request-reply and consume patterns, channel pooling and publisher confirms. Queue and exchange declarations can be driven from the DSL.

// Highlights

  • queueExchange / directExchange / topicExchange publishing
  • Request-reply with matchByMessageId or matchByCorrelationId
  • Full message-property DSL, all Gatling EL aware
  • Gatling 3.13.x · Scala 2.13 · Java 17+
scala · build.sbt + simulation
// build.sbt
libraryDependencies += "org.galaxio" %% "gatling-amqp-plugin" % "<version>" % Test

import org.galaxio.gatling.amqp.Predef._

val amqpConf = amqp
  .connectionFactory(
    rabbitmq.host("localhost").port(5672)
      .username("guest").password("guest").vhost("/")
  )
  .usePersistentDeliveryMode
  .matchByMessageId

scenario("AMQP Publish")
  .exec(
    amqp("publish").publish
      .queueExchange("test-queue")
      .textMessage("""{"msg": "hello"}""")
      .contentType("application/json")
  )

// About

Production-grade helpers on top of the core Gatling DSL: structured configuration, Faker-backed data feeders, signed JWTs, Redis-backed scenarios, reusable transaction blocks, NFR assertions and secret masking in logs.

// Highlights

  • SimulationConfig — shared baseUrl / intensity / durations with -D overrides
  • Faker API feeders, HC Vault, CSV and phone feeders
  • JWT (HS/RS/ES), transactions with their own latency stats
  • Gatling 3.13.x since 1.12.0 · Scala 2.13 · Java 17+
scala · build.sbt + simulation
// build.sbt
libraryDependencies += "org.galaxio" %% "gatling-picatinny" % "VERSION" % Test

import org.galaxio.gatling.config.SimulationConfig._
import org.galaxio.gatling.feeders.faker.Predef._

// shared config from simulation.conf, overridable with -D
val httpProtocol = http.baseUrl(baseUrl)

val users = GeneratedFeeder(
  "email" -> Faker.internet.email(),
  "phone" -> Faker.phone.mobile(Country.RU, PhoneFormatMode.E164),
)

rampUsersPerSec(0).to(intensity).during(rampDuration)

AI Plugins01

Our engineering practice, portable across agents

// About

Galaxio engineering workflows packaged as portable agent plugins. One plugin is authored once — a single skills/ tree per plugin generates the Cursor, Claude Code and Codex manifests from one source file. Ships galaxio-gatling-pro: Gatling JVM performance testing in Galaxio style.

// Highlights

  • galaxio-gatling-pro — Gatling 3.9.x–3.15.x, Scala/Java/Kotlin
  • sbt, Maven or Gradle · Picatinny · HTTP/JDBC/JMS/Kafka/AMQP
  • Generated manifests are never hand-edited — npm run check gates drift
  • Apache-2.0 · Node >= 22 · Agent Skills standard
shell · install
# Claude Code
$ claude plugin marketplace add galax-io/ai-plugins

# Codex
$ codex plugin marketplace add galax-io/ai-plugins

# then install the plugin by name
$ claude plugin install \
    galaxio-gatling-pro@galaxio-performance-kit

# Cursor: Dashboard -> Plugins -> Add Marketplace
#         -> Import from Repo

Core / Platform03

Scaffolding, templates and the CLI that ties them together

// About

A Go CLI for Gatling performance-testing workflows. Scaffolds ready-to-compile load-test projects from templates and generates Gatling scripts from Swagger/OpenAPI, HAR recordings or Postman collections. Ships with a default registry, so discovery works with no configuration.

// Highlights

  • template init / list — scaffold and discover templates
  • generate swagger / har / postman — scripts from an existing API spec
  • doctor — validate config and registry access · update — self-update
  • macOS, Linux, Windows · go install, shell installer, or Docker
shell
# install (macOS / Linux)
$ curl -fsSL https://raw.githubusercontent.com/galax-io/\
    galaxio-cli/main/scripts/install.sh | sh

# discover and scaffold
$ galaxio template list
$ galaxio template init gatling/scala-sbt \
    --set Name=orders-api \
    --set NameWord=ordersApi \
    -d ./perf-tests

# generate a simulation from an OpenAPI spec
$ galaxio generate swagger --from ./petstore.yaml --init

// About

The Gatling template pack for galaxio-cli. Six ready-to-compile templates covering Scala, Java and Kotlin on sbt, Maven and Gradle, with optional Kafka, JDBC and AMQP plugin modules rendered on demand.

// Highlights

  • scala-sbt · scala-gradle · java-maven · java-gradle · kotlin-maven · kotlin-gradle
  • Optional Kafka / JDBC / AMQP overlays via *PluginEnabled inputs
  • Every input overridable with --set or a --values YAML file
  • Pack 0.15.0 · Gatling 3.13.5 · Picatinny 1.17.1
shell
# scaffold, then enable optional plugin modules
$ galaxio template init gatling/scala-sbt \
    --set Name=my-service \
    --set NameWord=myservice \
    --set KafkaPluginEnabled=true \
    --set JdbcPluginEnabled=true \
    -d ./perf-tests

# compile the rendered project
$ cd perf-tests && sbt -batch Gatling/compile

// About

The default registry galaxio-cli reads from. Holds versioned project templates and their metadata, so the CLI can resolve a pack version to a GitHub release and render from it. Point the CLI elsewhere only when you need a private source.

// Highlights

  • Default source — github:galax-io/galaxio-template-registry
  • Pack version resolves to a GitHub release tag
  • Swap in your own with template configure --registry
shell
# the default registry needs no setup, but you can inspect it
$ galaxio template configure --show
$ galaxio doctor

# point at your own registry
$ galaxio template configure \
    --registry github:my-org/my-registry

# or a local checkout, for one command only
$ galaxio template init mypack/mytemplate \
    --registry local:/path/to/registry

Methodology / Process03

Spec-driven development for performance work

// About

A spec-driven-development methodology for performance and load testing, built on GitHub spec-kit. It encodes load-testing methodology patterns as a ratified constitution, so an engagement runs as a governed, traceable, gated pipeline instead of a pile of ad-hoc scripts.

// Highlights

  • Four phases, two front-door actors — bootstrap, order, spec & plan, build & run
  • NFR prose -> clarify -> EARS SLOs -> machine-readable nfr.yml
  • Shipped as a spec-kit bundle: preset + extension + workflow
  • Status: research & design — the design lives in docs/
shell · specify
# discover
$ specify preset search perf
$ specify extension search perf

# install
$ specify init --preset perf
$ specify extension add <id>

# run the gated pipeline
$ specify workflow run

// About

A Copier template for spinning up a new project with the Galaxio development process already wired in: spec-kit extensions and presets, the issue-PR-milestone linkage gate, and a stack-agnostic AGENTS.md / CLAUDE.md. The stack does not matter — the process is the same for every project.

// Highlights

  • Pick a stack (scala-sbt / jvm-gradle / node / python / go / generic) and defaults pre-fill
  • linkage-guard hook blocks release tagging unless issue-PR-milestone holds
  • copier update 3-way-merges later process changes into your project
  • Installs 7 spec-kit extensions + a preset
shell · copier
# install Copier once, isolated
$ uv tool install copier    # or: pipx install copier

# scaffold a new project (--trust runs post-gen tasks)
$ copier copy --trust \
    gh:galax-io/spec-kit-galaxio-bootstrap \
    ~/code/my-new-project

# later, pull template/process updates in
$ cd ~/code/my-new-project && copier update --trust

// About

A tool-agnostic format for performance requirements. One JSON Schema decides what a RequirementSet may say; a corpus of examples is validated against it on every commit. A requirement names its requests once, then states criteria — what must hold — and guards — whether the run that produced them meant anything. No tool is named anywhere in a document, and that is the one property the format will not trade away. Nothing reads a document yet: a requirement can be written, validated, reviewed and versioned, but not run.

// Highlights

  • selector says which requests · criteria what must hold · guards whether the run was valid
  • Predicates are structured — metric / aggregation / op / threshold / unit, no expression language to parse
  • A guard catches the run that aimed at 200 rps, pushed 5 and still went green
  • Apache-2.0 · JSON Schema Draft 2020-12 · v0.9.0, pre-1.0
yaml · requirementset
# examples/one-request-is-fast.yaml — the smallest document
apiVersion: opennfr.io/v1
kind: RequirementSet
metadata:
  name: checkout-perf

spec:
  requirements:
    - name: checkout
      selector:
        loadtest.request.name: POST /checkout
      criteria:
        - metric: loadtest.request.duration
          aggregation: p95
          op: lte
          threshold: 500
          unit: ms

# the schema, the corpus, the links and the language
$ bash scripts/verify.sh

Tooling / Infrastructure03

The supporting cast

// About

Adds an SBT task that downloads Avro and Protobuf schemas from a Confluent Schema Registry and generates sources from them, so generated code stays in sync with whatever your producers and consumers expect.

// Highlights

  • Download and generate Avro / Protobuf schemas
  • Keeps generated code in sync with the registry
  • Pairs with gatling-kafka-plugin Avro support
scala · plugins.sbt
// project/plugins.sbt
addSbtPlugin("org.galaxio" % "sbt-schema-registry-plugin" % "<version>")

// build.sbt — point at your registry
schemaRegistryUrl := "http://localhost:8081"

// download the schemas
$ sbt schemaRegistryDownload

// About

Container images used by Galaxio CI/CD pipelines and local development environments — pinned toolchains so a Gatling run behaves the same on a laptop and in CI.

// Highlights

  • Images for CI/CD and local development
  • Pinned JDK / build-tool versions
  • Reproducible across CI providers
shell
# the galaxio CLI is also published as an image
$ docker pull galaxioteam/galaxio:latest

$ docker run --rm \
    -v "$PWD":/work -w /work \
    galaxioteam/galaxio template list

// About

One canonical model for the results of a load test, a decoder per tool that produces it, and a statistics engine that answers the questions a report asks. It exists because Gatling stopped generating stats.json in 3.13.5 and since 3.13.0 writes simulation.log in an undocumented binary format only the exact same Gatling version can read. Nothing is implemented yet — the repository holds the scaffold, the backlog and a milestone per source.

// Highlights

  • model/ canonical types · gatling/ text and binary codecs · stats/ percentiles and series
  • Planned sources: Gatling 3.11–3.15, JMeter JTL, k6, Locust, Yandex.Tank phout
  • Every read version-gated — an older version refused, an unknown newer one decoded with a warning
  • MIT · Go · model and gatling depend on the standard library only
shell · go get + packages
# nothing is implemented yet — this is what is being built
$ go get github.com/galax-io/parsec

# the packages, once they exist
    model/    canonical result types shared by every source
    gatling/  text and binary codecs, version gate, discovery
    stats/    counts, timings, percentiles, per-interval series

# progress is public: small milestones, each ending in a tag
$ gh release list --repo galax-io/parsec
Archived

Built with contributors, maintainers and users.

We welcome issues, ideas, documentation improvements, and integrations that help the ecosystem grow.

§ 03 / Origin

The name Galaxio comes from Asimov's Galaxia.

Galaxia describes a future state where all planets, all humans, all life and even non-living organic matter are incorporated into one single organism.

We liked the idea because it reflects what we work on: coordination, scale, and systems working together as one. Plugins, integrations and workflows are the threads that hold a performance-testing toolchain together — the ecosystem is only as strong as the connections between its parts.

Need something urgent? We can fast-track it.

Critical features and integrations can be prioritized as a paid engagement. That is the fastest path when shipping speed matters more than waiting in the regular queue.

Get in touch