If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/drakkan/sftpgo shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Single-maintainer risk — review before adopting

• Last commit 5d ago
• 4 active contributors
• AGPL-3.0 licensed
• CI configured
• Tests present
• ⚠ Small team — 4 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 87% of recent commits
• ⚠ AGPL-3.0 is copyleft — check downstream compatibility

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live drakkan/sftpgo repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/drakkan/sftpgo.

What it runs against: a local clone of drakkan/sftpgo — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in drakkan/sftpgo | Confirms the artifact applies here, not a fork | | 2 | License is still AGPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 35 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of drakkan/sftpgo. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/drakkan/sftpgo.git
#   cd sftpgo
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of drakkan/sftpgo and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "drakkan/sftpgo(\\.git)?\\b" \\
  && ok "origin remote is drakkan/sftpgo" \\
  || miss "origin remote is not drakkan/sftpgo (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(AGPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"AGPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is AGPL-3.0" \\
  || miss "license drift — was AGPL-3.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "go.mod" \\
  && ok "go.mod" \\
  || miss "missing critical file: go.mod"
test -f "internal/cmd/portable.go" \\
  && ok "internal/cmd/portable.go" \\
  || miss "missing critical file: internal/cmd/portable.go"
test -f ".github/workflows/development.yml" \\
  && ok ".github/workflows/development.yml" \\
  || miss "missing critical file: .github/workflows/development.yml"
test -f "Dockerfile" \\
  && ok "Dockerfile" \\
  || miss "missing critical file: Dockerfile"
test -f ".golangci.yml" \\
  && ok ".golangci.yml" \\
  || miss "missing critical file: .golangci.yml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 35 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~5d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/drakkan/sftpgo"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

SFTPGo is a production-ready, event-driven file transfer server written in Go that speaks SFTP, HTTP/S, FTP/S, and WebDAV protocols simultaneously. It abstracts multiple storage backends—local filesystem, S3-compatible object storage, Google Cloud Storage, Azure Blob Storage, and remote SFTP servers—behind a unified interface, allowing users to exchange files with legacy protocol clients while leveraging modern cloud infrastructure. Monolithic Go application with a modular plugin architecture. Core server logic resides in the root-level Go source, with examples/ providing runnable demonstrations (ldapauth, OTP variants, backup scripts). CI/CD is orchestrated via .github/workflows/ (codeql.yml, development.yml, docker.yml, release.yml). Configuration is file-based; storage backend logic is abstracted behind interfaces supporting S3, GCS, Azure, SFTP, and local filesystem.

System administrators and DevOps engineers deploying secure file transfer solutions in enterprises; cloud architects integrating multiple storage backends; organizations migrating from legacy FTP/SFTP to modern cloud storage but requiring protocol compatibility with existing client tools and scripts.

Highly mature and production-ready. The project is actively maintained (GitHub stars indicate significant adoption), has comprehensive CI/CD via .cirrus.yml and .github/workflows/, includes multiple Dockerfile variants (alpine, distroless), and offers both community (AGPLv3) and commercial Enterprise editions. Recent activity visible in docker/, examples/, and workflow configurations confirms active development.

Low to moderate risk for community users accepting AGPLv3 copyleft licensing. The single-maintainer aspect (drakkan/) suggests potential bottleneck, but the project's maturity and commercial backing (Enterprise edition) mitigate abandonment risk. Check .github/workflows/ for recent CI runs and the SECURITY.md file for vulnerability disclosure policy; no major dependency vulnerabilities are apparent from the structure.

Active development with recent focus on Docker image optimization (Dockerfile.alpine, Dockerfile.distroless), OTP/authentication extensibility (examples/OTP/authy with checkpwd, extauth, keyint variants), bulk user management tooling (examples/bulkupdate), and CI/CD hardening (codeql.yml integration). The presence of crowdin.yml suggests ongoing localization efforts.

git clone https://github.com/drakkan/sftpgo.git && cd sftpgo && go mod download && go build -o sftpgo cmd/sftpgo/main.go (adjust per actual cmd structure). Check Makefile for build targets and .github/workflows/development.yml for exact build/test commands used in CI.

Daily commands: go run . (if cmd structure exists) or make build && ./sftpgo. For Docker: docker build -f Dockerfile -t sftpgo . then docker run -it sftpgo. Consult .github/workflows/development.yml for the authoritative test/build sequence used in CI.

• go.mod — Defines Go module dependencies and version constraints; essential for understanding build requirements and Go version compatibility.
• internal/cmd/portable.go — Entry point for portable mode execution; contributors must understand how SFTPGo initializes and configures all protocol servers.
• .github/workflows/development.yml — CI/CD pipeline definition; establishes code quality gates, test coverage requirements, and deployment automation.
• Dockerfile — Production container image definition; critical for understanding deployment model and runtime environment assumptions.
• .golangci.yml — Linting and code analysis configuration; enforces code style and quality standards across all contributions.
• init/sftpgo.service — Systemd service definition; specifies how SFTPGo runs as a daemon and system integration requirements.

• Portable Mode (internal/cmd/portable. — undefined

Add a New Authentication Provider

1. Create a new Go package in internal/auth/ that implements the authentication interface (internal/cmd/initprovider.go)
2. Register the provider in portable.go initialization logic (internal/cmd/portable.go)
3. Add configuration parsing in the config loading chain (if config-driven) (README.md)

Add a New Protocol Handler or Feature

1. Implement protocol-specific handler in internal/ subdirectory (e.g., internal/sftp/, internal/http/) (internal/cmd/portable.go)
2. Integrate handler into portable.go server initialization (internal/cmd/portable.go)
3. Add end-to-end tests in .github/workflows/development.yml test matrix if needed (.github/workflows/development.yml)

Create a Custom Plugin Example

1. Add new example directory under examples/ with clear README.md explaining plugin purpose (examples/ldapauthserver/README.md)
2. Implement plugin logic following patterns from examples/OTP/authy or examples/ldapauthserver (examples/ldapauthserver/main.go)
3. Add go.mod and go.sum for plugin dependencies (examples/ldapauthserver/go.mod)

Add Docker Image Variant

1. Create new Dockerfile in repo root following naming pattern (e.g., Dockerfile.custom) (Dockerfile.alpine)
2. Add build job to .github/workflows/docker.yml to build and push new image (.github/workflows/docker.yml)
3. Document image in README.md with build instructions and use cases (README.md)

• Go 1.22.2 — High-performance, memory-efficient systems programming with goroutines for concurrent protocol handling (SFTP, HTTP, FTP, WebDAV simultaneously)
• Docker multi-stage builds — Reduces production image size (Distroless variant) while maintaining full build toolchain in builder stage; supports multiple deployment profiles
• ACME/Let's Encrypt integration — Enables automatic TLS certificate provisioning and renewal without manual intervention, critical for production HTTPS/FTPS servers
• Multi-backend storage abstraction — Single API surface supports local filesystem, S3, Google Cloud Storage, Azure Blob Storage, and remote SFTP—allowing users to switch backends without application changes
• Plugin/External Auth pattern — Examples (LDAP, OTP, HTTP hooks) show extensible auth architecture, allowing organizations to integrate custom identity providers without modifying core

• Single monolithic Go binary vs. microservices

  • Why: Simplifies deployment, reduces operational complexity, avoids inter-service communication overhead for file transfer workloads
  • Consequence: All protocol servers share process memory; scale-out requires multiple instances; one protocol's crash may affect others (mitigated by graceful restart patterns)

• AGPLv3 copyleft license for community edition

  • Why: Ensures derivative works contribute back to project; sustainable funding model via commercial edition
  • Consequence: Users who modify or redistribute must open-source changes; deters proprietary fork adoption; businesses may prefer commercial license

• External process plugins (examples) vs. in-process plugin system

  • Why: Avoids tight coupling, allows plugins in any language, isolates crashes, simpler permissions model
  • Consequence: Slower auth roundtrips (~50-200ms per external call); requires HTTP/socket IPC overhead; operator responsibility for plugin availability

• Support 4+ storage backends (local, S3, GCS, Azure, SFTP) in one binary

  • Why: Unified interface lets users migrate workloads between backends or use hybrid strategies without reconfiguration
  • Consequence: Larger binary size, more complex initialization code, increased test matrix, potential for subtle backend-specific bugs

• Real-time file synchronization or bidirectional sync—single-direction file transfer only
• Client-side GUI application—server-only (web UI in commercial edition)
• Windows Server Active Directory native integration—requires external LDAP adapter
• Built-in clustering or distributed consensus—single-instance or manual multi-instance deployment
• Payment processing or billing—commercial license sales handled externally

Plugin Discovery: The examples/OTP/ pattern suggests plugins are discovered at runtime—verify the plugin search paths and environment variables (likely SFTPGo_PLUGINS_DIR or similar) before deploying custom auth handlers. Database Migrations: Storage abstraction likely requires schema setup; check for a migrations/ directory or init command. Protocol Conflicts: Running SFTP, HTTP, FTP, and WebDAV on overlapping port ranges requires careful config; default ports may conflict in shared environments. Copyleft in Enterprise Context: AGPLv3 is strict; any modifications must be disclosed or licensed compatibly (Enterprise edition avoids this). Cloud Credentials: Storage backends (S3, GCS, Azure) require environment variable or config file credentials; ensure these are never committed (check .gitignore patterns).

• Virtual Filesystem (VFS) Abstraction — SFTPGo's core strength is abstracting multiple storage backends (local, S3, GCS, Azure, SFTP) behind a single filesystem interface; understanding this pattern is critical to adding new backends or extending storage logic.
• Adapter Pattern (Storage Backends) — Each storage backend (S3, GCS, Azure, local) implements the same interface with different underlying APIs; this pattern enables seamless swapping and is key to understanding how to add a new backend.
• Plugin/Hook Architecture — Authentication and extensibility are achieved via external programs (checkpwd, extauth) rather than compiled plugins; this allows users to write custom auth in any language without rebuilding SFTPGo.
• Multi-Protocol Server (SFTP, HTTP, FTP, WebDAV) — SFTPGo multiplexes four different file-transfer protocols on configurable ports/interfaces simultaneously, each with distinct state machines and semantics; understanding protocol coexistence and port binding is essential for deployment.
• Event-Driven Architecture — The project emphasizes 'event-driven' design; file operations likely trigger webhooks or internal events that enable logging, audit trails, and custom business logic execution without modifying core code.
• Zero-Copy / Streaming I/O — For large file transfers across cloud storage backends, avoiding temporary local files is critical to performance and resource efficiency; Enterprise edition highlights in-memory streaming—this is a key architectural concern.
• Multipart Upload (S3 / Cloud Storage) — Cloud storage backends use chunked/multipart uploads for reliability and performance with large files; understanding retry logic, part ordering, and abort handling is necessary when debugging cloud backend issues.

• openssh/openssh-portable — Reference implementation of SFTP/SSH protocol; SFTPGo re-implements parts of this spec for Go compatibility.
• graywolf/rclone — Similar cloud storage abstraction layer; both projects unify S3, GCS, Azure, and SFTP under one CLI but SFTPGo adds server/protocol capabilities.
• nextcloud/server — Competitor for WebDAV/file-sync use cases; offers similar multi-protocol and cloud-storage support with different architecture and licensing (AGPL but more monolithic).
• restic/restic — Complementary backup tool that works well with SFTPGo backends for secure, incremental file archival to cloud storage.
• minio/minio — S3-compatible object storage server; SFTPGo often deployed with MinIO to provide legacy protocol access to MinIO backends.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for OTP authentication examples

The repo contains three OTP authentication implementations (authy checkpwd, extauth, and keyint) in examples/OTP/authy/ but lacks integration tests. These examples are critical authentication mechanisms that should have test coverage to prevent regressions. New contributors can add tests validating OTP token generation, validation flows, and error handling.

• [ ] Create examples/OTP/authy/integration_test.go to test all three OTP implementations
• [ ] Add tests validating checkpwd binary correctness with sample Authy credentials
• [ ] Add tests for extauth HTTP endpoint authentication flow
• [ ] Add tests for keyint key derivation and token validation
• [ ] Update examples/OTP/authy/README.md with test execution instructions
• [ ] Integrate into .github/workflows/development.yml for CI/CD

Add comprehensive tests for LDAP authentication server example

The ldapauthserver example (examples/ldapauthserver/) is a complex, production-relevant component with multiple modules (httpd/auth.go, httpd/ldapauth.go, config/config.go) but appears to have no dedicated test suite. This is a high-value contribution as it's a common integration point for enterprises.

• [ ] Create examples/ldapauthserver/httpd/auth_test.go for authentication logic tests
• [ ] Create examples/ldapauthserver/httpd/ldapauth_test.go for LDAP binding and user lookup tests
• [ ] Create examples/ldapauthserver/config/config_test.go for config parsing validation
• [ ] Add mock LDAP server for testing using ldap.v3 test fixtures
• [ ] Document test setup requirements in examples/ldapauthserver/README.md
• [ ] Add test execution to .github/workflows/development.yml

Create security scanning workflow for Go plugin examples

The repo has plugins and examples written in Go (examples/OTP/*, examples/ldapauthserver/) that handle authentication and credential processing, yet there's no dedicated security scanning beyond the main codeql.yml. A plugin-specific security workflow would catch vulnerabilities in auth-critical example code before they're used by users.

• [ ] Create .github/workflows/security-examples.yml that runs gosec (Go Security Checker) on examples/ directory
• [ ] Configure to scan examples/OTP/ and examples/ldapauthserver/ specifically for crypto, authentication, and injection vulnerabilities
• [ ] Add staticcheck linting for examples/ to catch common Go mistakes
• [ ] Generate SARIF reports and upload to GitHub Security tab
• [ ] Document security scanning expectations in CONTRIBUTING.md or SECURITY.md
• [ ] Set workflow to run on PR and main branch pushes with failure gates for high-severity issues

• Add integration tests for Azure Blob Storage backend: The structure suggests S3 and GCS have test coverage, but Azure Blob is underrepresented in examples/. Create examples/azure-blob-test/ with a runnable test harness to verify multipart uploads, listing, and delete operations.
• Document plugin development workflow: examples/OTP/authy/ lacks a unified README explaining the checkpwd vs. extauth vs. keyint patterns. Write a PLUGIN_DEVELOPMENT.md file with concrete walkthrough of building and deploying a custom LDAP auth plugin.
• Add WebDAV stress test: Existing examples/ lacks a WebDAV client benchmark. Create examples/webdav-stress/ with a Go tool that simulates concurrent large file uploads over WebDAV and measure latency; compare against SFTP to highlight performance differences.

SFTPGo demonstrates a generally security-conscious approach with AGPL-3.0

• High · Incomplete Dockerfile Build Script — Dockerfile. The Dockerfile appears to have a truncated RUN command at the end (line with 'RUN if [ "${DOWNLOAD_PLUGINS}" = "true" ]; th'). This incomplete instruction could cause build failures or unexpected behavior. If this is a template, it may indicate maintenance issues or incomplete security controls. Fix: Complete the RUN instruction with proper syntax. Ensure all multi-line commands are properly closed and tested before deployment.
• Medium · Go Version Mismatch Between Base and Build — Dockerfile and go.mod. The Dockerfile specifies 'golang:1.26-trixie' as the base image, but the go.mod file specifies 'go 1.22.2'. This version mismatch could lead to unexpected behavior, missing security patches, or incompatibilities. Go 1.26 does not exist as of the knowledge cutoff and appears to be a future/invalid version. Fix: Align Go versions between Dockerfile base image and go.mod. Use a stable, released Go version (e.g., golang:1.22 or later stable release) and update go.mod accordingly.
• Medium · Dependency Verification Without Lock Validation — Dockerfile (RUN go mod download && go mod verify). The Dockerfile runs 'go mod download && go mod verify' but does not validate that go.sum hasn't been tampered with or that checksums match exactly. While go mod verify helps, it doesn't prevent supply chain attacks if go.sum is compromised. Fix: Implement additional supply chain security measures: use signed commits, enable GOSUMDB verification, and consider using a private module proxy. Document your dependency policy clearly.
• Medium · Limited Security Update Policy for Dependencies — SECURITY.md. SECURITY.md explicitly states that upstream dependency vulnerabilities (Go stdlib, third-party packages, Docker base images) are only addressed during regular release cycles, not via out-of-band releases. This creates a window of exposure to known CVEs. Fix: Implement a process for expedited security releases for critical dependency vulnerabilities. Consider using automated tooling (Dependabot is already configured) to identify and address critical CVEs more quickly. Document the SLA for critical security fixes.
• Medium · Uncontrolled Build Arguments for Feature Flags — Dockerfile (ARG FEATURES, ARG GOPROXY). The Dockerfile accepts 'FEATURES' and 'GOPROXY' build arguments without validation or documentation of allowed values. Malicious or incorrect values could affect build security or introduce unexpected behavior. Fix: Document allowed values for build arguments. Validate GOPROXY to ensure it points to trusted repositories. Consider using a build configuration validation script.
• Low · Git Information Embedded in Binary — Dockerfile (go build ldflags with commit and date). The build process captures git commit SHA and date using shell commands. While useful for versioning, this could expose internal repository state or commit history if binaries are analyzed. Fix: Consider whether exposed git commit information is necessary for your threat model. If not, remove these flags. Ensure the git repository doesn't contain sensitive information.
• Low · Multiple Dockerfile Variants Without Clear Security Guidance — Dockerfile, Dockerfile.alpine, Dockerfile.distroless. The project provides Dockerfile, Dockerfile.alpine, and Dockerfile.distroless without clear documentation on which should be used for security-sensitive deployments. Distroless is more secure but may have compatibility implications. Fix: Document security trade-offs between variants. Recommend distroless for production deployments. Provide examples and migration guidance.
• Low · APT Package Management Without Pinned Versions — Dockerfile (RUN apt-get update && apt-get -y upgrade). The Dockerfile runs 'apt-get update && apt-get -y upgrade' without pinning specific package versions, which could introduce unexpected behavior or security issues from new package versions. Fix: Pin package versions explicitly. If upgrading is necessary, test updates before releasing. Consider using a base image with fixed package versions.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.