Jinsi ya kusakinisha Superlog kwenye VPS yako

Kile ambacho Superlog ya kujihostisha husakinisha

Ili kujihostisha Superlog, unaclonerepository, unawasha Postgres, ClickHouse na OpenTelemetry collector kwa kutumia Docker Compose, unafanya migration moja ya database, kisha unaanzisha huduma nne za Node kutoka kwenye source code. Programu zako hutuma traces, logs na metrics za OTLP (OpenTelemetry protocol) kwenye port ya kupokelea, Superlog huzichakata kwa kuzitambua (fingerprinting), huzikundi zile zinazojirudia kuwa tukio moja (incident), na wakala (agent) huandika uchambuzi wa awali. Usakinishaji huchukua mchana mmoja. Ukubwa wa rasilimali zinazohitajika na mipaka ya kweli ni mambo yanayostahili kusomwa kabla ya kuanza.

Superlog ina leseni ya Apache 2.0 na inapatikana katika github.com/superloglabs/superlog. Kufikia Agosti 2026, ina takriban nyota 1.2k, karibu commits 460 kwenye main, na haina tags zozote za release. Jambo hilo la mwisho huathiri usakinishaji: git checkout v1.0.0 haina kitu cha kuchagua (checkout), kwa hivyo unajichagulia commit mwenyewe au unaendesha chochote kile ambacho main ilikuwa nacho asubuhi uliyoclone.

Mambo ambayo Superlog inajibu ambayo Uptime Kuma na Langfuse hazijibu

Zana za ufuatiliaji (monitoring tools) zinazojiendesha kwenye seva yako zinaonekana kufanana kwa nje. Hivyo sivyo, na kutumia zana isiyo sahihi kutakugharimu seva bila faida yoyote.

• Uptime Kuma huchunguza (probe) endpoints zako kutoka nje na kujibu swali moja: je, huduma inafanya kazi?
• Zabbix hufuatilia hosts na huduma kwenye Ubuntu 24.04, ikijumuisha CPU, kumbukumbu, diski na hali ya huduma dhidi ya vizingiti (thresholds) ulivyoweka.
• Langfuse hufuatilia (trace) miito ya LLM, ikirekodi prompt, modeli, token, latency na gharama ya kila mmoja.
• Superlog huchukua telemetry ambayo huduma zako za kawaida tayari zinatoa na kugeuza hitilafu zinazojirudia kuwa matukio (incidents).

Superlog inajibu swali tofauti: kitu kimeharibika, ni nini kimeharibika, na kwa nini. Haina maoni kuhusu miito ya LLM na haikuchunguzi kutoka nje. Inapokea OTLP kutoka kwa msimbo wa programu yako ya kawaida na kuweka wakala (agent) kwenye hatua ya triage, ambayo ndiyo hatua ya kwanza ambayo binadamu aliye zamu angefanya hata hivyo.

Tofauti muhimu kwa bajeti ya VPS ni hifadhi (storage). Uptime Kuma hufanya kazi vizuri kwenye 1 GB ya RAM kwa sababu inahifadhi maelfu machache ya matokeo ya ukaguzi. Superlog inabeba column store, kwa sababu telemetry huandikwa mara moja na kisha kutafutwa kwa muda (time range) katika mamilioni ya safu. Hilo ndilo kusudi la ClickHouse na si Postgres. Postgres bado inabaki kwenye stack, ikishikilia data ndogo za uhusiano: miradi, watumiaji, matukio na funguo za kuingiza data (ingest keys).

Amri ya docker compose up -d inaanza nini hasa?

Kontena tatu, na hakuna hata moja kati ya hizo ni Superlog. Hili huwashangaza watu wanaotarajia usakinishaji wa amri moja.

• postgres:16, iliyochapishwa kwenye port ya seva ya 5434
• clickhouse/clickhouse-server:26.1, kwenye 8123 kwa ajili ya HTTP na 9000 kwa ajili ya itifaki asilia
• otel/opentelemetry-collector-contrib:0.150.1, kwenye 4317 kwa ajili ya gRPC na 4318 kwa ajili ya OTLP kupitia HTTP

Programu za Superlog huendeshwa kwenye seva (host), kutoka kwenye source, zikianzishwa na pnpm dev. Hakuna faili ya uzalishaji ya compose kwenye hazina (repository) kufikia Agosti 2026, kwa hivyo usakinishaji wa kudumu unamaanisha unapaswa kuunda systemd units zako mwenyewe kuzunguka kila hati ya start ya programu, au kutumia Dockerfiles za kila programu zinazokuja na mfumo huu.

Kumbuka njia ambayo span inafuata, kwa sababu kila hitilafu hapa chini ni kukatika kwa hatua moja ya njia hiyo. Programu yako hutuma OTLP kwenye wakala wa mapokezi (intake proxy) wa Superlog. Wakala huyo huhakiki ombi hilo kwa kutumia ufunguo wako wa kuingiza data (ingest key), huweka kitambulisho cha mradi (project id) juu yake, na kulipeleka kwa mtoza data (collector). Mtoza data huondoa sifa zozote za superlog.* ambazo mteja alijaribu kuziweka, huongeza superlog.project_id kutoka kwenye header iliyotolewa na wakala, hufanya batching, na kuandika kwenye ClickHouse. Programu ya wavuti na API kisha husoma telemetry kutoka ClickHouse na kila kitu kingine kutoka Postgres.

Uondoaji huo wa sifa ni udhibiti halisi wa multi-tenancy, si mapambo tu. Bila hatua hiyo, mtu yeyote aliye na ufunguo mmoja halali wa kuingiza data angeweza kujiwekea superlog.project_id na kuandika data kwenye mradi wa mtu mwingine.

VPS inahitaji kuwa na ukubwa gani?

Panga kuwa na 4 vCPU, 8 GB ya RAM na 40 GB ya SSD kwa ajili ya usakinishaji wa node moja kwa kiasi kidogo cha data inayoingia. Hii ni kiwango cha chini cha kupanga, si kipimo kamili, kwa hivyo ichukulie kama saizi ya kuanzia na uikague kulingana na trafiki yako.

Kumbukumbu inagawanywa katika sehemu nne. ClickHouse imejengwa kwa ajili ya mashine zenye RAM ya kutosha na mipangilio yake chaguomsingi inadhani hivyo. Postgres 16 ni ya kawaida hapa, kwa sababu inahifadhi metadata badala ya telemetry. Mkusanyaji (collector) pia ni wa kawaida. Michakato minne ya Node si ya kawaida: seva ya maendeleo ya Vite pamoja na michakato mitatu ya tsx watch kila moja inashikilia mamia ya megabytes, ndiyo maana pnpm dev kwenye mashine ya 2 GB ni ngumu.

Disk ni tatizo lisiloonekana sana. pnpm install kwenye monorepo hii inavuta AWS SDK, mteja wa ClickHouse, OpenTelemetry SDK na zana za React kabla hata hujapokea span moja. ClickHouse kisha hukua kulingana na trafiki yako. Pima vyote viwili:

df -h /
free -m
docker stats --no-stream
docker compose exec clickhouse clickhouse-client --database superlog --query "SELECT table, formatReadableSize(sum(bytes_on_disk)) AS size FROM system.parts WHERE active AND database = 'superlog' GROUP BY table ORDER BY sum(bytes_on_disk) DESC"

Kwa kiasi kidogo cha data, huduma chache zinazotuma mamia machache ya spans kwa dakika, mashine huwa tulivu na ClickHouse huwa haifanyi kazi nyingi muda mwingi. Mzigo unaoumiza ni ule wa ghafla: deploy mbaya inayozalisha maelfu ya makosa yanayofanana kwa dakika. Fingerprinting huunganisha hayo kuwa tukio moja kwa msomaji, lakini ClickHouse bado huandika kila mstari chini yake.

Uhifadhi (retention) ni wako wa kuweka. ClickHouse exporter ya mkusanyaji hutengeneza majedwali, otel_traces, otel_logs na jedwali moja kwa kila aina ya metric, na inatumia muda wa kuishi (time to live) ikiwa tu usanidi katika infra/collector/config.yaml utaweka hivyo. Hakuna kinachokwisha muda wake chenyewe, kwa hivyo mwezi wenye shughuli nyingi utasababisha disk kujaa isipokuwa kama utapanga mapema.

Kusakinisha kutoka kwa commit iliyobandikwa (pinned)

git clone https://github.com/superloglabs/superlog.git
cd superlog
git tag -l
git log -1 --format='%H %cs %s'

git tag -l kutotoa matokeo yoyote ndilo jambo linalotarajiwa kufikia Agosti 2026. Chagua commit uliyojaribu na ubaki nayo:

git checkout 0d3a6c8bb63eda3493e6ba0003e7c2a70750bc1e

Inayofuata ni toolchain:

node -v
corepack enable
corepack prepare pnpm@9.12.0 --activate
pnpm -v

package.json inatangaza engines.node kama >=20.0.0 na packageManager kama pnpm@9.12.0. Endesha usakinishaji kwenye Node ya zamani na pnpm itasimama na ERR_PNPM_UNSUPPORTED_ENGINE, ikitaja toleo ililohitaji. Kifurushi cha nodejs katika hazina (archive) ya Ubuntu 24.04 ni cha zamani kuliko 20, kwa hivyo sakinisha Node 20 au mpya zaidi kutoka NodeSource au nvm. Hazina hiyo inatoa .nvmrc, kwa hivyo nvm use huchagua toleo lililokusudiwa ikiwa unatumia nvm.

pnpm install
docker compose up -d
docker compose ps

Subiri ukaguzi wa afya (health checks) badala ya kuamini kuwa up -d inamaanisha iko tayari. Postgres na ClickHouse zote zinatangaza moja kwenye faili ya compose:

curl -sS http://127.0.0.1:8123/ping
pg_isready -h 127.0.0.1 -p 5434 -U postgres

ClickHouse inajibu Ok. na pg_isready inajibu accepting connections. Connection refused kwenye 8123 inamaanisha kontena bado linaanza au limekufa. docker compose logs clickhouse inaonyesha hali halisi, na docker inspect $(docker compose ps -q clickhouse) | grep -i oomkilled inaripoti true wakati kernel imelisitisha kwa sababu ya kumbukumbu, jambo linaloashiria kuwa seva ni ndogo badala ya kuwa na hitilafu kwenye usanidi wako.

Kisha uhamiaji (migration) na programu:

pnpm --filter @superlog/db db:migrate
pnpm dev

Zingatia port: 5434, si 5432. Faili ya compose inachapisha Postgres kwenye 5434 ili isigongane na Postgres iliyosakinishwa tayari kwenye seva, na faili za .env.example za programu zinalingana, na DATABASE_URL=postgres://postgres:postgres@localhost:5434/superlog. Ukielekeza uhamiaji kwenye 5432 kwenye seva inayotumia Postgres tayari, utapata connection refused au, mbaya zaidi, uhamiaji utafanyika kwenye database isiyo sahihi.

pnpm dev inaanza michakato minne iliyoorodheshwa kwenye Procfile ya hazina: api, web, worker na proxy. Kila moja inaelekeza matokeo yake kwenye tmp/logs/, kwa hivyo tail -f tmp/logs/proxy.log ndipo unapofuatilia uingizaji wa data. README inaweka programu ya web kwenye http://localhost:5173, API kwenye http://localhost:4100 na OTLP intake kwenye http://localhost:4101.

Thibitisha kile kilichofungwa (bound) kabla ya kuelekeza chochote kwacho:

ss -lntp | grep -E '4100|4101|5173'
curl -sS http://127.0.0.1:4101/health

Hili ni muhimu baadaye. Proxy inasoma port yake kutoka kwa kigezo cha mazingira (environment variable) cha PORT na inarudi kwenye 4000 wakati PORT haijawekwa. Stack ya maendeleo (development stack) inakuwekea kigezo hiki. Unit ya systemd unayoandika mwenyewe haifanyi hivyo, kwa hivyo exporter inayolenga 4101 dhidi ya proxy inayoisikiliza 4000 itashindwa na connection refused bila kukupa dalili nyingine yoyote.

Tuma trace moja, zalisha hitilafu moja, ona tukio moja

Tengeneza mradi katika web app na unakili ingest key yake. Mfumo wa intake huhakiki kila ombi dhidi ya key hiyo, kwa hivyo telemetry inayotumwa bila key haifiki kwenye ClickHouse.

Elekeza SDK yoyote ya OpenTelemetry kwenye intake kwa kutumia environment variables za kawaida:

export OTEL_SERVICE_NAME=checkout-api
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_ENDPOINT=http://127.0.0.1:4101
export OTEL_EXPORTER_OTLP_HEADERS='x-api-key=YOUR_INGEST_KEY'

Intake husoma key kutoka kwenye header ya x-api-key, na pia hukubali authorization: bearer YOUR_INGEST_KEY ikiwa exporter yako ni rahisi kusanidiwa kwa njia hiyo. Inahudumia njia tatu za kawaida za OTLP, /v1/traces, /v1/logs na /v1/metrics, pamoja na /health.

Mtego mmoja unastahili kutajwa. OTEL_EXPORTER_OTLP_ENDPOINT ni base URL na SDK huongeza signal path kwenye URL hiyo. Variable mahususi za signal kama OTEL_EXPORTER_OTLP_TRACES_ENDPOINT hutumika kama zilivyoandikwa, bila kuongezewa path yoyote. Ukiweka variable mahususi ya signal kuwa http://127.0.0.1:4101, kila export itatumwa kwenye /, ambayo si route sahihi; kwa hivyo hakuna kitakachofika na SDK itaandika hitilafu ya export kwenye log wakati app yako inaonekana kuwa sawa.

Kwa huduma ya Node, njia ya zero code inatosha kuthibitisha pipeline:

npm install @opentelemetry/api @opentelemetry/auto-instrumentations-node
node --require @opentelemetry/auto-instrumentations-node/register server.js

Sasa haribu kitu kwa makusudi. Route yoyote inayozalisha exception itafaa:

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/boom

Kagua hatua za mtiririko (hops) kwa mpangilio, kwa sababu pengo la kwanza litakuonyesha ni wapi palipofeli:

tail -n 50 tmp/logs/proxy.log
docker compose exec clickhouse clickhouse-client --database superlog --query 'SELECT count() FROM otel_traces'

Idadi inayoongezeka katika otel_traces huku web app ikiwa tupu inaashiria kutolingana kwa mradi, kwa hivyo kagua mradi ambao ingest key hiyo inahusika nao. Idadi isiyobadilika huku kukiwa na shughuli katika proxy log inaashiria tatizo kwenye collector au uandikaji wa ClickHouse, kwa hivyo soma docker compose logs collector. Kutokuwepo kwa shughuli yoyote katika proxy log kunamaanisha kuwa exporter haikufika kwenye intake: port isiyo sahihi, path isiyo sahihi, au key iliyokataliwa.

Katika web app, hitilafu hizo zinazojirudia hufika kama tukio moja (incident) badala ya mstari mmoja kwa kila ombi. Superlog huchunguza alama za signal zinazoingia na kuzipanga zile zinazolingana, jambo ambalo ni tofauti kati ya inbox iliyojaa hitilafu 4,000 zinazofanana na ukurasa ulio na tukio moja. Wakala (agent) kisha huandika uchunguzi wake juu ya kundi hilo.

Hatua ya uchunguzi huita model, kwa hivyo worker inahitaji model provider iliyosanidiwa. Chukua majina ya variable hizo kutoka kwenye faili la .env.example ndani ya kila saraka ya app ya commit uliyoiweka (pinned) badala ya kutumia maelezo ya nje, kwa sababu hubadilika kulingana na main. Hali hiyo hiyo inatumika kwa GitHub na Sentry integrations, ambazo zina nyaraka zao za usanidi katika docs/github-app-setup.md na docs/sentry-app-setup.md, huku webhook payloads zikiwa zimeandikwa katika docs/webhooks.md.

Weka mlango wa kuingilia ukiwa wa faragha, na wakala uwe wa kusoma pekee

Docker huchapisha port za container kwenye 0.0.0.0 kwa chaguomsingi, na port hizo zilizochapishwa hupita pembeni ya ufw, kwa sababu Docker huandika sheria zake kwenye chain ya DOCKER-USER ambazo hupitiwa kabla ya ufw kuona pakiti. Kwenye VPS yenye IP ya umma, faili ya compose kama ilivyosafirishwa huweka ClickHouse HTTP kwenye 8123 na Postgres kwenye 5434 ambapo intaneti inaweza kuzifikia. Vitambulisho vilivyomo kwenye faili hiyo ni vya maendeleo: mtumiaji wa ClickHouse default akiwa na nenosiri tupu, Postgres ikiwa na postgres kama mtumiaji na nenosiri.

Zifunge kwenye loopback. Kila port iliyochapishwa kwenye faili ya compose huchukua upande wake wa host kutoka kwa environment variable, kwa hivyo .env kwenye mzizi wa hazina (repository root) inatosha:

POSTGRES_HOST_PORT=127.0.0.1:5434
CLICKHOUSE_HTTP_HOST_PORT=127.0.0.1:8123
CLICKHOUSE_TCP_HOST_PORT=127.0.0.1:9000
COLLECTOR_GRPC_HOST_PORT=127.0.0.1:4317
COLLECTOR_HTTP_HOST_PORT=127.0.0.1:4318

Thibitisha matokeo kabla ya kuyaamini, kisha tengeneza upya containers:

docker compose config
docker compose up -d
ss -lntp | grep -E '5434|8123|9000|4317|4318'

docker compose config huchapisha faili iliyosuluhishwa, kwa hivyo unaweza kusoma 127.0.0.1:5434:5432 badala ya kukisia. ss inapaswa kuonyesha 127.0.0.1:5434 na kamwe isionyeshe 0.0.0.0:5434. Usijaribu kurekebisha hili kwa faili ya compose override inayotangaza upya ports, kwa sababu Compose huunganisha orodha za port kwenye faili badala ya kuzibadilisha, kwa hivyo utaishia na bindings zote mbili na ile ya umma ikiwa bado wazi.

Mlango wa kuingilia (intake) unahitaji uangalifu uleule. Ufunguo wako wa kuingiza data (ingest key) husafiri kwenye header, kwa hivyo unahitaji TLS (transport layer security) mbele yake: malizia TLS kwenye nginx au Caddy mbele ya proxy, au weka ingest ndani ya mtandao wa faragha au WireGuard tunnel. Programu ya wavuti kwenye 5173 ni seva ya maendeleo ya Vite na haina sababu ya kukabili intaneti hata kidogo.

Kisha wakala (agent) wenyewe. Ahadi ya Superlog ni kwamba wakala huchunguza na kupendekeza marekebisho, na neno muhimu hapa ni kupendekeza. Iweke iwe ya kusoma pekee (read only) dhidi ya uzalishaji (production) hadi utakapoiangalia ikifanya kazi kwenye matukio machache halisi. Ipe GitHub App wigo wa kusoma (read scopes) na uiruhusu ifungue pull requests unazozikagua. Wakala anayesoma telemetry na kuandika patch ni muhimu. Wakala anayeweza kuanzisha upya huduma zako ni kiwango tofauti cha hatari, na hilo linapaswa kuwa uamuzi unaoufanya kwa makusudi badala ya chaguomsingi unayorithi. Gharama inastahili uangalifu uleule, kwa kuwa kila uchunguzi ni wito wa mfano (model call): bajeti kwa ajili ya matumizi ya wakala kwenye VPS kabla ya kuielekeza kwenye mfumo wa uzalishaji wenye kelele, na weka rekodi ya kile wakala alichokifanya hasa ili pull request ya kushangaza iwe na njia ya ukaguzi (audit trail) nyuma yake.

Hitilafu utakazokutana nazo, na misemo inayozitaja

• ERR_PNPM_UNSUPPORTED_ENGINE wakati wa pnpm install inamaanisha Node ni ya toleo la zamani kuliko 20. node -v inathibitisha hili kwa mstari mmoja.
• ECONNREFUSED 127.0.0.1:5434 wakati wa uhamiaji inamaanisha kuwa compose stack haijawashwa, au DATABASE_URL inataja port isiyo sahihi.
• ClickHouse kuanza upya mara kwa mara kwa kawaida ni tatizo la kumbukumbu. Soma docker compose logs clickhouse, kisha kagua container ili kuona kama OOMKilled ni true.
• Exporter inayoripoti mafanikio wakati web app inabaki tupu kwa kawaida inamaanisha data ilienda moja kwa moja kwa collector kwenye 4318, jambo linaloruka uwekaji wa alama (stamping) wa mradi unaofanywa na proxy.
• Connection refused kwenye 4101 katika usakinishaji wa uzalishaji inamaanisha proxy ilirejea kwenye PORT=4000. Weka PORT wazi kwenye unit file.
• docker compose ps inayoonyesha 0.0.0.0:8123 inamaanisha kuwa loopback bindings zako hazifanyi kazi. Tekeleza docker compose config na usome port zilizotatuliwa.

Flawless, HyperProbe, na mahali ambapo Superlog inakaa

Kategoria hii ni changa, na zana zake hutofautiana kuhusu kile ambacho wakala (agent) anaruhusiwa kukigusa. Flawless ni zana ya AI SRE (site reliability engineering) ya chanzo huria inayolenga Kubernetes, ikisoma kutoka kwenye stack iliyopo ya Prometheus, Loki na Grafana badala ya kumiliki pipeline yenyewe. HyperProbe inafuata mkondo tofauti: ni bidhaa inayohifadhiwa (hosted product), ambayo haijafunguliwa chanzo chake (closed source) kufikia Agosti 2026, inayoweka probes za kusoma pekee (read-only) ndani ya mchakato unaoendelea ili kunasa hali ya vigezo (variable state) na kuifichua hali hiyo kwa msaidizi kupitia MCP (model context protocol).

Superlog inakaa katikati ya hizi mbili. Inamiliki pipeline kuanzia mwanzo hadi mwisho, kuanzia upokeaji wa OTLP hadi hifadhi ya ClickHouse, na inaweka wakala kwenye hatua ya utatuzi (triage) badala ya hatua ya kurekebisha. Usanifu huo ndio hasa sababu inayofanya kujiendeshea (self-hosting) Superlog kuwa uamuzi wa miundombinu na si kontena unalolisahau. Mara tu unapoendesha Superlog, unaendesha hifadhi ya safuwima (column store), na inahitaji uangalizi uleule kama hifadhidata nyingine yoyote unayomiliki.

FAQ

Superlog inayojiendesha inahitaji RAM kiasi gani?

Panga kuwa na 8 GB ya RAM, 4 vCPU na 40 GB ya diski kwa node moja yenye kiasi kidogo cha data. Stack hii inajumuisha Postgres, ClickHouse, OpenTelemetry collector na michakato minne ya Node, na ClickHouse inahitaji nafasi ya ziada ya kumbukumbu. VPS ya 1 GB au 2 GB haitoshi: pnpm install pekee ni nzito, na ClickHouse huuwawa na kernel kupitia out of memory killer inapokuwa na mzigo. Pima takwimu zako mwenyewe kwa kutumia docker stats --no-stream na free -m badala ya kuamini takwimu zozote zilizochapishwa, ikiwemo hii.

Ninaelekeza OTLP exporter yangu kwenye port ipi?

Kwenye Superlog intake proxy, ambayo README huiweka kwenye http://localhost:4101. Inahudumia /v1/traces, /v1/logs na /v1/metrics, na inathibitisha utambulisho kwa kutumia ingest key ya mradi wako inayochukuliwa kutoka kwenye header ya x-api-key au kutoka kwenye header ya authorization: bearer. Port 4318 ni ya OpenTelemetry collector iliyo chini yake, na ku-export moja kwa moja huko kunaruka proxy, ambayo ndiyo sehemu inayoweka kitambulisho cha mradi wako kwenye data. Proxy hurejea kwenye port 4000 wakati PORT haijawekwa, kwa hiyo endesha ss -lntp na uthibitishe ilikojifunga kabla ya kudhani ni 4101.

Je, Superlog inachukua nafasi ya Uptime Kuma au Zabbix?

Hapana. Uptime Kuma hujibu kama endpoint inajibu kutoka nje ya mtandao wako, na Zabbix hufuatilia metrics za host na huduma dhidi ya vizingiti ulivyoweka. Superlog huchakata traces, logs na metrics zinazotolewa na programu zako na kupanga makosa yanayojirudia kuwa matukio (incidents). Weka probe ya nje ya uptime pembeni yake, kwa sababu probe inayofanya kazi mahali pengine bado itatoa taarifa wakati seva inayoshikilia telemetry pipeline yako ndiyo iliyokufa.

Je, Superlog agent inaweza kubadilisha mifumo yangu ya production?

Kupitia ruhusa unazozitoa pekee. Matokeo yake ni uchunguzi na mabadiliko yaliyopendekezwa ambayo binadamu huyapitia. Weka GitHub App kwenye scopes za kusoma pekee (read scopes) na pull requests mwanzoni, na weka credentials zozote ambazo mfanyakazi anazo ziwe na ukomo wa kusoma tu. Chukulia uwezo wa kuandika (write access) kwenye production kama uamuzi tofauti unaofanywa kwa makusudi, kwa sababu agent inayoweza kuanzisha upya huduma ni ahadi kubwa zaidi kuliko agent inayosoma telemetry na kuandika patch kwa ajili ya mapitio.

Je, niweke commit maalum au nifuatilie main?

Weka commit maalum. Hakuna release tags kwenye repository kufikia Agosti 2026, kwa hiyo main ndiyo target pekee inayopatikana na hupata commit kadhaa kwa wiki. Rekodi SHA uliyojaribu, deploy hiyo, na usome diff kabla ya kusonga mbele. git log --oneline <old-sha>..main ndiyo sehemu ya mapitio, na faili za .env.example za kila programu ndiyo sehemu ya kwanza ya kuangalia vigezo vipya vinavyohitajika baada ya mabadiliko yoyote.