LinkBreeze-ஐ VPS-ல் Docker Compose மூலம் நிறுவுவது எப்படி?

LinkBreeze என்றால் என்ன

LinkBreeze என்பது சுய-வழங்கப்பட்ட (self-hosted) Linktree மாற்றாகும்: இது ஒரு பொதுவான link-in-bio பக்கத்தையும், நிர்வாகக் கட்டுப்பாட்டுப் பலகத்தையும் (admin dashboard) வழங்கும் ஒரே Docker container ஆகும். இதன் அனைத்துத் தரவுகளும் ஒரே SQLite கோப்பில் சேமிக்கப்படுகின்றன. இது MIT உரிமம் பெற்றது, TypeScript மற்றும் Next.js கொண்டு உருவாக்கப்பட்டது, மேலும் ghcr.io/manak-hash/linkbreeze ஆக வெளியிடப்பட்டுள்ளது. இதை இயக்க உங்களுக்கு ஒரு VPS, அந்த VPS-ஐச் சுட்டிக்காட்டும் A record கொண்ட ஒரு domain, திறக்கப்பட்ட 80 மற்றும் 443 ports, மற்றும் Compose plugin உடன் கூடிய Docker Engine தேவை.

இந்த வழிகாட்டி, repository-ஆல் ஆதரிக்கப்படும் deployment முறையை விளக்குகிறது: இது சொந்தமாக certificates-ஐப் பெறும் reverse proxy-க்கு பின்னால் இயங்கும் Docker Compose ஆகும். இது எதனால் செயலிழக்கக்கூடும் என்பதையும் விளக்குகிறது, ஏனெனில் link-in-bio என்பது மற்றவர்கள் கிளிக் செய்யும் ஒரு பொதுவான URL ஆகும், அது செயலிழந்தால் உங்கள் பார்வையாளர்களை இழக்க நேரிடும்.

இதற்கு முன்பாக, இந்தத் திட்டம் எவ்வளவு புதியது என்பதைத் தெளிவாகப் புரிந்துகொள்ளுங்கள்.

பொதுப் பயன்பாட்டிற்கான profile link-க்கு LinkBreeze போதுமான முதிர்ச்சியுடன் உள்ளதா?

ஆகஸ்ட் 2026 நிலவரப்படி, இந்த repository 178 stars, 17 forks மற்றும் ஒரே ஒரு maintainer-ஐக் கொண்டுள்ளது. இதன் முதல் tagged release-ஆன v1.0.0, ஜூலை 1, 2026 அன்று வெளியிடப்பட்டது. இது சில ஆண்டுகள் பழமையான திட்டம் அல்ல, சில வாரங்களே ஆன புதிய திட்டமாகும்.

[
  {
    "week": "2026-06-29",
    "releases": 3,
    "cumulative": 3
  },
  {
    "week": "2026-07-06",
    "releases": 3,
    "cumulative": 6
  },
  {
    "week": "2026-07-13",
    "releases": 1,
    "cumulative": 7
  },
  {
    "week": "2026-07-20",
    "releases": 2,
    "cumulative": 9
  },
  {
    "week": "2026-07-27",
    "releases": 3,
    "cumulative": 12
  },
  {
    "week": "2026-08-03",
    "releases": 2,
    "cumulative": 14
  },
  {
    "week": "2026-08-10",
    "releases": 3,
    "cumulative": 17
  }
]

v1.0.0 பதிப்பிற்குப் பிறகு, இந்தத் திட்டம் 17 tagged releases-ஐ 7 வாரங்களில் வெளியிட்டுள்ளது. இந்த வழிகாட்டி எழுதப்படும்போது அந்த அட்டவணையின் கடைசி வாரம் இன்னும் முடிவடையவில்லை, அதற்குள்ளேயே 3 releases வெளியிடப்பட்டிருந்தன.

இதை இரண்டு தனித்தனி உண்மைகளாகக் கருதவும். maintainer சுறுசுறுப்பாகச் செயல்படுகிறார், பிழைகள் சில நாட்களிலேயே சரிசெய்யப்படுகின்றன. அதேசமயம், schema மற்றும் defaults இன்னும் மாற்றங்களுக்கு உள்ளாகின்றன; எனவே, நீங்கள் deploy செய்துவிட்டு கவனிக்காமல் விடும் ஒரு instance, தற்போதைய code-லிருந்து வெகுவாக மாறுபட்டுவிடும்.

இதன் license உங்களை மோசமான சூழலில் இருந்து பாதுகாக்கிறது. MIT license, ஒரு container image மற்றும் உங்கள் disk-ல் உள்ள ஒரு SQLite file ஆகியவை இருப்பதால், மேம்பாடு நிறுத்தப்பட்டாலும், உங்களிடம் உள்ள மென்பொருள் தொடர்ந்து இயங்கும். ஆனால், பாதுகாப்புத் திருத்தங்கள் (security fixes) கிடைக்காத ஒரு public-facing web app, காலப்போக்கில் ஒரு பொறுப்பாக (liability) மாறும் என்பதில் இருந்து இது உங்களைப் பாதுகாக்காது. எனவே, தொடர்ந்து update செய்து பராமரிக்கக்கூடிய ஒரு திட்டமாக இதை deploy செய்யுங்கள், மேலும் கீழே கொடுக்கப்பட்டுள்ள backup முறையை முதல் நாளிலிருந்தே சரியாகப் பின்பற்றுங்கள்.

Image tag-ஐ pin செய்யவும், latest-ஐ பயன்படுத்த வேண்டாம்

Release workflow ஒவ்வொரு version-க்கும் சரியாக இரண்டு tags-ஐ push செய்கிறது: latest, மற்றும் v நீக்கப்பட்ட version எண். எனவே, v1.2.7 release-க்கான pinned tag என்பது ghcr.io/manak-hash/linkbreeze:1.2.7 ஆகும். :v1.2.7 என்று எழுதினால் எதையும் pull செய்ய முடியாது, மேலும் அந்த tag ஒருபோதும் push செய்யப்படாததால் Docker manifest unknown என்ற பிழையைக் காட்டும்.

latest தொடர்ந்து மாறிக்கொண்டே இருப்பதால், அதை pin செய்வது அவசியம். மேலே உள்ள அட்டவணையில் உள்ள வேகத்தில், latest-க்கு எதிராக ஒரு docker compose pull செய்வது என்பது, உங்கள் பயனர்கள் பயன்படுத்தும் பக்கத்தை எந்தவித மறுஆய்வும் இன்றி upgrade செய்வதற்குச் சமம். Pinned tag-ஐப் பயன்படுத்தினால், நீங்கள் கோப்பைத் திருத்தும்போது மட்டுமே upgrade நிகழும்.

Image குறித்து மேலும் ஒரு விஷயம். Release workflow எந்தவொரு platforms: அமைப்பும் இன்றி build செய்யப்படுகிறது, எனவே வெளியிடப்பட்ட image linux/amd64 மட்டுமே. ஒரு arm64 host-ல் pull செய்ய முயன்றால் no matching manifest for linux/arm64/v8 in the manifest list entries பிழையுடன் அது தோல்வியடையும். நீங்கள் x86-க்கு பதிலாக ARM VPS-ஐப் பயன்படுத்துகிறீர்கள் என்றால், அந்த machine-லேயே image-ஐ build செய்யவும்:

git clone --branch v1.2.7 --depth 1 https://github.com/Manak-hash/LinkBreeze.git
cd LinkBreeze
docker build -t linkbreeze:1.2.7 .

அதன்பிறகு, கீழே உள்ள compose கோப்பில் image பெயராக linkbreeze:1.2.7-ஐப் பயன்படுத்தவும்.

LinkBreeze-ஐ Caddy-க்கு பின்னால் தானியங்கி TLS உடன் நிறுவுதல்

Caddy, Let's Encrypt-லிருந்து சான்றிதழ்களைத் தானாகவே கோரி புதுப்பித்துக்கொள்ளும், எனவே TLS (transport layer security)-க்குத் தனிப்பட்ட சான்றிதழ் படிநிலைகள் தேவையில்லை. முழு நிறுவலையும் ஒரே கோப்பகத்தில் உள்ள மூன்று கோப்புகள் மூலம் செய்து முடிக்கலாம்.

முதலில் secret-ஐ உருவாக்கவும்:

mkdir -p ~/linkbreeze && cd ~/linkbreeze
printf 'SECRET_KEY=%s\n' "$(openssl rand -hex 32)" > .env
chmod 600 .env

SECRET_KEY, admin session cookie-ஐ sign செய்யவும், analytics visitor hash-க்கு salt சேர்க்கவும் பயன்படுகிறது. களஞ்சியத்தில் (repository) உள்ள compose கோப்பு இதை இயல்பாக ${SECRET_KEY:-changeme-in-production} என அமைக்கிறது. எனவே, இந்த படிநிலையைத் தவிர்த்தால், GitHub-ல் பகிரங்கமாகத் தெரியும் session signing key-ஐக் கொண்டு உங்கள் instance இயங்கும். முதல்முறை தொடங்குவதற்கு முன்பே இதை அமைக்கவும்; ஏனெனில், பிறகு மாற்றினால் நீங்கள் logout செய்யப்படுவீர்கள் மற்றும் analytics salt மீட்டமைக்கப்படும்.

docker-compose.yml-ஐ எழுதவும்:

services:
  linkbreeze:
    image: ghcr.io/manak-hash/linkbreeze:1.2.7
    restart: unless-stopped
    volumes:
      - linkbreeze-data:/app/data
    environment:
      - DATABASE_PATH=/app/data/linkbreeze.db
      - SECRET_KEY=${SECRET_KEY}
      - BASE_URL=https://links.example.com
    networks:
      - linkbreeze-net

  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy-data:/data
      - caddy-config:/config
    networks:
      - linkbreeze-net

networks:
  linkbreeze-net:

volumes:
  linkbreeze-data:
  caddy-data:
  caddy-config:

BASE_URL என்பது விருப்பத்தேர்வு, ஆனால் இதை அமைப்பது சிறந்தது. இது application-க்கு அதன் உண்மையான public முகவரியைத் தெரிவிக்கும். இதனால், போலியான Host header-உடன் வரும் கோரிக்கைகள் மூலம், வேறொருவரின் domain-க்கு link-களை உருவாக்க application-ஆல் முடியாது.

Caddyfile-ஐ அதன் அருகில் உங்கள் domain-உடன் எழுதவும்:

links.example.com {
    encode zstd gzip
    reverse_proxy linkbreeze:3000
}

Caddy இயல்பாகவே proxied கோரிக்கைகளில் X-Forwarded-For மற்றும் X-Forwarded-Proto ஆகியவற்றை அமைக்கும், இதுவே analytics-ன் செயல்பாட்டிற்குத் தேவைப்படுகிறது. இதைத் தொடங்கவும்:

docker compose up -d
docker compose ps
docker compose logs -f caddy

docker compose ps கட்டளை LinkBreeze container-ஐ healthy நிலையில் காட்ட வேண்டும். இந்த image-ல் wget --spider -q http://127.0.0.1:3000/api/health என்ற healthcheck உள்ளமைக்கப்பட்டுள்ளது, எனவே நீங்கள் தனியாகச் சேர்க்கத் தேவையில்லை. களஞ்சியத்தில் உள்ள Caddy உதாரணத்திலிருந்து healthcheck-ஐ நகலெடுக்க வேண்டாம்: அது curl-ஐ அழைக்கிறது, ஆனால் இந்த image node:22-alpine-ஐ அடிப்படையாகக் கொண்டது. இதில் busybox wget மட்டுமே உள்ளது, curl இல்லை. அந்த container பக்கங்களைச் சரியாக வழங்கினாலும் unhealthy என்ற நிலையையே காட்டும்.

உலாவியில் https://links.example.com-ஐத் திறக்கவும். முதல் வருகை /setup-ல் உள்ள setup wizard-க்குச் செல்லும், இதுவே ஒரே admin கணக்கை உருவாக்கும். அதன் பிறகு dashboard /dashboard-லும், login படிவம் /login-லும் இருக்கும். அந்தக் கணக்கு இந்த instance-க்கு மட்டுமே உரியது, இதில் single sign-on வசதி இல்லை. எனவே, நீங்கள் ஹோஸ்ட் செய்யும் பிற சேவைகளைப் போலவே இதற்கும் ஒரே login-ஐப் பயன்படுத்த விரும்பினால், அதற்கு முன்னால் a self-hosted Authentik போன்ற forward auth proxy-ஐப் பயன்படுத்த வேண்டும்.

Compose கோப்பு எதைச் செய்யவில்லை என்பதைக் கவனிக்கவும்: அது port 3000-ஐப் பகிரங்கமாகத் திறக்காது. Caddy மட்டுமே public interface-ல் கேட்கும் (listen). Compose கோப்பு முறை உங்களுக்குப் புதியது என்றால், the Docker Compose basics for a VPS இந்த கோப்பு சார்ந்த அடிப்படை விஷயங்களை விளக்குகிறது. நீங்கள் ஏற்கனவே வேறு ஏதேனும் proxy-ஐப் பயன்படுத்துகிறீர்கள் என்றால், Nginx, Caddy and Traefik compared என்ன மாற்றங்கள் தேவை என்பதை விளக்குகிறது. களஞ்சியத்தில் Nginx with Certbot, Traefik மற்றும் Cloudflare tunnel-க்கான வேலை செய்யும் உதாரணங்கள் உள்ளன.

உங்கள் தரவு எங்கு சேமிக்கப்படுகிறது மற்றும் பேக்கப்பில் என்ன இருக்க வேண்டும்

DATABASE_PATH என்பது /app/data/linkbreeze.db-ஐக் குறிக்கிறது. பதிவேற்றப்பட்ட அவதாரங்கள் (avatars) மற்றும் இணைப்புகளின் சிறுபடங்கள் (link thumbnails) அதன் அருகிலேயே /app/data/uploads-ல் எழுதப்படுகின்றன. இவை இரண்டும் linkbreeze-data என்ற named volume-ல் இருப்பதால், பேக்கப் எடுக்கும்போது database கோப்பை மட்டும் எடுக்காமல், முழு volume-ஐயும் எடுக்க வேண்டும். பதிவேற்றங்கள் உள்ள கோப்பகம் (directory) இல்லாமல் தரவுத்தளத்தை மட்டும் மீட்டெடுத்தால், பக்கத்தில் உள்ள அனைத்து படங்களும் 404 பிழையைக் காட்டும்.

மற்ற அனைத்து தரவுகளும் அந்த ஒரே தரவுத்தளத்தில் தான் உள்ளன: பக்கங்கள், இணைப்புகள், அமைப்புகள், தீம், மின்னஞ்சல் சந்தாதாரர்கள் மற்றும் அனலிட்டிக்ஸ் வரிசைகள்.

Container-ஐ நிறுத்திய பிறகு நகலை எடுக்கவும்:

docker compose stop linkbreeze
docker compose cp linkbreeze:/app/data ./backup-$(date +%F)
docker compose start linkbreeze

செயல்முறை (process) தரவுத்தளத்தில் எழுதிக்கொண்டிருக்கும்போது நகலெடுத்தால், முழுமையடையாத பரிவர்த்தனை (transaction) பதிவாகி, கோப்பு சிதைந்துவிட வாய்ப்புள்ளது. எனவே, நகலெடுக்கும் முன் நிறுத்துவது அவசியம். நகலெடுக்கும் நேரத்தில் பக்கம் offline-ல் இருக்கும். மீட்டெடுப்பதும் இதே முறையைத் தலைகீழாகச் செய்வதாகும்:

docker compose stop linkbreeze
docker compose cp ./backup-2026-08-14/. linkbreeze:/app/data
docker compose start linkbreeze
docker compose logs -f linkbreeze

Dashboard-ல் JSON export வசதியும் உள்ளது, இது /api/backup-லிருந்து linkbreeze-backup-YYYY-MM-DD.json ஆக வழங்கப்படுகிறது. இதில் profile, இணைப்புகள், அமைப்புகள் மற்றும் சேமிக்கப்பட்ட தீம்கள் இருக்கும். இதில் அனலிட்டிக்ஸ் வரலாறு, மின்னஞ்சல் சந்தாதாரர்கள் அல்லது பதிவேற்றப்பட்ட படங்கள் இருக்காது. இதை மீட்டெடுக்கும்போது, அந்த நான்கு அட்டவணைகளில் உள்ள தற்போதைய வரிசைகள் நீக்கப்பட்டு, கோப்பில் உள்ளவை சேர்க்கப்படும். இதை host-ஐ மாற்றுவதற்கோ அல்லது எடிட்டிங் பிழைகளைச் சரிசெய்வதற்கோ ஒரு config snapshot-ஆகப் பயன்படுத்தவும். Volume நகலே உண்மையான பேக்கப் ஆகும்.

VPS-ல் SQLite-ஐ இயக்கும்போது மற்ற இடங்களைப் போலவே இங்கும் இரண்டு சேமிப்பக விதிகள் பொருந்தும். தரவுத்தளத்தை local disk-ல் வைத்திருக்கவும், ஏனெனில் network filesystem-ல் SQLite-ன் locking நம்பகத்தன்மையற்றது, இது தரவுத்தளத்தைச் சிதைக்கக்கூடும். நீங்கள் named volume-க்கு பதிலாக host bind mount-ஐப் பயன்படுத்தினால், முதலில் host கோப்பகத்திற்கு chown செய்யவும்: container-ஆனது root அல்லாத node பயனராக, node:22-alpine-ல் uid 1000-ஆக இயங்குகிறது. root-ஆல் உருவாக்கப்பட்ட கோப்பகத்தில் இந்த பயனரால் எழுத முடியாது என்பதால், app-ஆல் தரவுத்தளத்தைத் திறக்க முடியாமல் container தொடக்கத்திலேயே நின்றுவிடும். Compose-ல் Bind mounts மற்றும் named volumes இதைப் பற்றிய முழுமையான விளக்கத்தை வழங்குகிறது.

Analytics மற்றும் consent banner உங்களுக்குத் தேவையில்லை

வேறு இடங்களில் இலவசமாகக் கிடைக்கும் ஒரு பக்கத்தை நீங்களே self-host செய்வதற்கு இந்த அம்சம் தான் முக்கியக் காரணம்.

இந்த analytics-ல் cookies பயன்படுத்தப்படுவதில்லை. பார்வையாளருக்கு எந்த cookie-யும் அமைக்கப்படுவதில்லை, பொதுப் பக்கத்தில் எந்த மூன்றாம் தரப்பு script-ம் ஏற்றப்படுவதில்லை. பார்வையாளர், IP address, user agent string மற்றும் ஒரு salt ஆகியவற்றின் SHA-256 hash மூலம் அடையாளம் காணப்படுகிறார்; இது 16 hexadecimal எழுத்துக்களாகச் சுருக்கப்படுகிறது. இந்த salt, தற்போதைய UTC தேதி மற்றும் உங்கள் SECRET_KEY ஆகியவற்றின் hash ஆகும். எனவே, இது UTC நள்ளிரவில் மாறுகிறது, நேற்றைய hash-களை இன்றைய hash-களுடன் ஒப்பிட முடியாது. மூல IP address தரவுத்தளத்தில் ஒருபோதும் எழுதப்படுவதில்லை.

கிளிக்குகள் server-ல் கணக்கிடப்படுகின்றன. பொதுப் பக்கத்தில் உள்ள ஒவ்வொரு http இணைப்பும் உங்கள் சொந்த domain-ல் உள்ள /go/<id>-ஐச் சுட்டிக்காட்டுகிறது. இது கிளிக்கைப் பதிவு செய்து, உண்மையான இலக்குக்கு 302 redirect மூலம் பதிலளிக்கிறது. எனவே, JavaScript முடக்கப்பட்ட வாசகர்களுக்கும், பின்னணி கோரிக்கைகளைத் தடுக்கும் in-app browsers-களிலும் இந்த எண்ணிக்கை சரியாகச் செயல்படுகிறது. பக்கப் பார்வைகள் /api/track மூலம் பதிவு செய்யப்படுகின்றன.

இரண்டு விலக்குகளைத் தெரிந்துகொள்வது அவசியம். செல்லுபடியாகும் admin session கொண்ட கோரிக்கைகள் தவிர்க்கப்படுகின்றன, எனவே உங்கள் சொந்தப் பக்கத்தைத் திருத்தும்போது எண்ணிக்கை அதிகரிக்காது. அறியப்பட்ட crawler user agents-களும் தவிர்க்கப்படுகின்றன.

Consent குறித்து: வாசகரின் சாதனத்தில் எதுவும் சேமிக்கப்படுவதில்லை. cookie banner என்பது வாசகரின் சாதனத்தில் சேமிக்கப்படும் cookie-க்கு அனுமதி கேட்பதாகும். உங்கள் வாசகர்கள் வசிக்கும் இடத்தைப் பொறுத்து உங்கள் கடமைகள் மாறுபடலாம், எனவே அவற்றைச் சரிபார்க்கவும். ஆனால், இங்கே வெளிப்படுத்த எந்த tracking cookie-யும் இல்லை, தரவைப் பெறும் மூன்றாம் தரப்பினரும் இல்லை.

மக்களை ஆச்சரியப்படுத்தும் ஒரு எச்சரிக்கை: SECRET_KEY-ஐ மாற்றினால், தினசரி salt-ம் அதனுடன் சேர்ந்து மாறிவிடும். எனவே, அந்த நொடியிலிருந்து மீண்டும் வரும் ஒவ்வொரு பார்வையாளரும் புதியவராகவே கணக்கிடப்படுவார்கள்.

அனலிட்டிக்ஸ் (analytics) பகுதியில் உள்ள நாடு (country) நெடுவரிசை ஏன் காலியாக உள்ளது?

உங்கள் stack-ல் எந்தவொரு பகுதியும் நாட்டுத் தகவலைக் கொண்ட header-ஐ அமைப்பதில்லை என்பதே இதற்குக் காரணம். LinkBreeze, cf-ipcountry மற்றும் x-vercel-ip-country போன்ற proxy headers மூலம் நாட்டைத் தீர்மானிக்கிறது. உங்கள் சொந்த Caddy அல்லது Nginx-க்கு பின்னால் உள்ள ஒரு VPS-ல், இந்த headers எதுவும் இருப்பதில்லை. எனவே, நாடு null என்று பதிவாகிறது மற்றும் அந்தப் பிரிவு காலியாகவே இருக்கும். container-க்குள் GeoIP database எதுவும் இல்லை.

இதைச் சரிசெய்ய இரண்டு வழிகள் உள்ளன. உங்கள் domain-க்கு முன்னால் Cloudflare-ஐப் பயன்படுத்தவும்; இது தான் proxy செய்யும் ஒவ்வொரு கோரிக்கையிலும் cf-ipcountry-ஐச் சேர்க்கும். அல்லது, உங்கள் சொந்த reverse proxy-ல் உள்ளூர் GeoIP lookup மூலம் அந்த headers-ல் ஒன்றைத் தாங்களே அமைக்கலாம்.

இதனுடன் தொடர்புடைய மற்றொரு சிக்கல் மிகவும் முக்கியமானது, அதைச் சரிபார்க்கவும். click மற்றும் view handlers, client முகவரியை முதலில் X-Forwarded-For-லிருந்து படிக்கின்றன, பிறகு X-Real-IP-லிருந்து படிக்கின்றன, இவை இரண்டும் இல்லையெனில் 0.0.0.0-ஐப் பயன்படுத்துகின்றன. எந்தவொரு proxy-யும் இல்லாமல் port 3000-ஐ நேரடியாக இணையத்தில் திறந்தால், அனைத்துப் பார்வையாளர்களும் ஒரே மதிப்பாகக் கருதப்படுவார்கள். இதனால் unique visitors எண்ணிக்கை எப்போதும் 1 என்றே இருக்கும், மேலும் ஒரு IP-க்கு நிமிடத்திற்கு 60 நிகழ்வுகள் என்ற rate limit உங்கள் ஒட்டுமொத்த பார்வையாளர்களுக்கும் ஒரே நேரத்தில் பொருந்தும். மேலே உள்ள reverse_proxy directive-க்கு பின்னால் வைக்கும்போது, Caddy உங்களுக்காக அந்த header-ஐ அமைத்துவிடும், இதனால் இரண்டு சிக்கல்களும் நீங்கிவிடும்.

Linktree-லிருந்து இறக்குமதி செய்தல் மற்றும் எவை இடம்பெறாது

Dashboard-ல் உள்ள migration wizard, ஒரு public profile URL-ஐ அல்லது export செய்யப்பட்ட கோப்பை ஏற்றுக்கொள்கிறது. இது linktr.ee, bento.me, lnk.bio, tap.link, hopp.bio, beacons.ai, solo.to, linkfly, mssg.me மற்றும் LittleLink பக்கங்களையும், பொதுவான HTML மற்றும் JSON கோப்புகளையும் அடையாளம் காணும். Linktree அல்லது Bento URL-களுக்கு, அந்தப் பக்கங்களில் உள்ள __NEXT_DATA__ JSON தரவை இது வாசிக்கும். Static பக்கங்களுக்கு, இது anchor tags-ஐ வாசிக்கும்.

ஒவ்வொரு இணைப்பின் தலைப்பு (title), URL, விளக்கம் (description) மற்றும் படம், அந்த இணைப்பு ஒரு social profile-ஆ என்பது, மற்றும் உங்கள் display name, bio, avatar ஆகியவை இடம்பெறும். தரவுத்தளத்தில் (database) சேமிப்பதற்கு முன்பு, கண்டறியப்பட்ட இணைப்புகளில் எவற்றை வைத்திருக்க வேண்டும் என்பதை நீங்கள் தேர்வு செய்யலாம்.

Analytics வரலாறு, theme மற்றும் layout, email subscribers, திட்டமிடப்பட்ட வெளியீட்டுத் தேதிகள் (scheduled publish dates) மற்றும் பழைய தளத்தின் login-க்கு பின்னால் உள்ள எவையும் இடம்பெறாது. தோற்றத்தை நீங்களே மீண்டும் உருவாக்கத் திட்டமிடுங்கள்; பழைய click வரலாறு அந்தப் பழைய சேவையிலேயே தங்கிவிடும் என்பதை ஏற்றுக்கொள்ளுங்கள்.

Importer உங்கள் browser-லிருந்து அல்லாமல், உங்கள் server-லிருந்து URL-ஐப் பெறுகிறது, எனவே public-ஆக இல்லாத முகவரிகளை இது நிராகரிக்கும். Private/local URLs are not allowed என்பது உங்கள் சொந்த network-க்குள் இருக்கும் ஒரு முகவரியை நீங்கள் கொடுத்தீர்கள் என்று பொருள்; இந்த நிராகரிப்பு வேண்டுமென்றே செய்யப்படுகிறது: இது இல்லையெனில், dashboard access உள்ள எவரும் உங்கள் server-ஐப் பயன்படுத்தி, உங்கள் server-ஆல் மட்டுமே அணுகக்கூடிய பிற இயந்திரங்களைச் சோதிக்க (probe) முடியும். நீங்கள் காணக்கூடிய பிற செய்திகள் Only http and https URLs are allowed, Request timed out மற்றும் Response too large ஆகும்.

Scraping என்பது மற்றவர்களின் markup-ஐச் சார்ந்தது. இணைப்புகள் தெளிவாகத் தெரியும் ஒரு பக்கத்தில் wizard எதையும் கண்டறியவில்லை என்றால், அந்தத் தளம் அதன் HTML-ஐ மாற்றியிருக்கிறது என்று பொருள். சரிசெய்யப்படும் வரை காத்திருக்காமல், இணைப்புகளை நீங்களே கைமுறையாகச் சேர்க்கவும். உங்களுக்கு ஒரு profile பக்கத்தை விட, அளவிடக்கூடிய short links தேவைப்பட்டால், Shlink போன்ற ஒரு self-hosted URL shortener அந்த வேலையைச் செய்யும், மேலும் அது அதே server-ல் சிறப்பாக இயங்கும்.

Pinned deployment-ஐ மேம்படுத்துதல்

# edit the image tag in docker-compose.yml, then
docker compose pull
docker compose up -d
docker compose logs -f linkbreeze

Container தொடங்கும் போது, schema migrations தானாகவே இயங்கும். இவற்றை முந்தைய நிலைக்குக் கொண்டு செல்ல (backwards) ஆவணப்படுத்தப்பட்ட வழிமுறை எதுவும் இல்லை, எனவே முதலில் volume-ஐ நகலெடுத்துக் கொள்ளவும். மாற்ற முடியாத ஒரு மேம்படுத்தல், அதற்கு முந்தைய நிலையை உங்களால் மீட்டெடுக்க முடிந்தால் மட்டுமே பாதுகாப்பானது.

புதிய release கிடைக்கும்போது dashboard-ல் ஒரு banner தோன்றும். இது 24 மணி நேரத்திற்கு ஒருமுறை project-ன் GitHub repository-லிருந்து சிறிய version file-ஐப் பெற்று சரிபார்க்கிறது; உங்கள் instance குறித்த எந்தத் தகவலையும் இது அனுப்புவதில்லை. tag-ஐ மாற்றுவதற்கு முன் release notes-ஐப் படிக்கவும், ஏனெனில் இந்த project-ன் தற்போதைய நிலையில், ஒரு minor version நீங்கள் சார்ந்திருக்கும் defaults-ஐ மாற்றக்கூடும்.

தோல்வி முறைகள் மற்றும் நீங்கள் காணும் சரங்கள் (strings)

manifest unknown இழுக்கும்போது (pulling). tag என்பது :v1.2.7 என்று எழுதப்பட்டது. Registry tags-ல் v இருப்பதில்லை, எனவே :1.2.7-ஐப் பயன்படுத்தவும்.

no matching manifest for linux/arm64/v8 in the manifest list entries. வெளியிடப்பட்ட image, amd64-க்கு மட்டுமே. tagged source-லிருந்து ARM host-ல் அதை build செய்யவும்.

பக்கம் சரியாக ஏற்றப்படும்போது, container unhealthy என்று காட்டுகிறது. உங்கள் compose file-ல் உள்ள healthcheck, curl-ஐ அழைக்கிறது, ஆனால் அந்த image-ல் அது இல்லை. அதை நீக்கிவிட்டு, அந்த image-ன் சொந்த wget healthcheck-ஐ இயங்க விடவும்.

Caddy certificate பிழையை வழங்குகிறது, அல்லது எதுவுமே காட்டவில்லை. docker compose logs caddy-ஐச் சரிபார்க்கவும். பொதுவாக, A record இன்னும் இந்த VPS-ஐச் சுட்டிக்காட்டாமல் இருப்பது அல்லது firewall-ல் port 80 மூடப்பட்டிருப்பதுதான் இதற்குக் காரணம். இது Caddy பயன்படுத்தும் ACME (automatic certificate management environment) HTTP challenge-ஐத் தடுக்கிறது, இதன் மூலம் தான் Caddy அந்த domain-ஐக் கட்டுப்படுத்துவதை உறுதி செய்கிறது.

தனித்துவமான பார்வையாளர்கள் (Unique visitors) எண்ணிக்கை 1-லேயே நிற்கிறது. எந்த proxy-யும் X-Forwarded-For-ஐ அமைக்கவில்லை, எனவே ஒவ்வொரு பார்வையாளரும் ஒரே மாதிரியாக hash செய்யப்படுகிறார்கள்.

நேற்று சரியாக இயங்கிய container, தொடங்கியவுடன் வெளியேறுகிறது. நீங்கள் named volume-லிருந்து host bind mount-க்கு மாறியிருந்தால், அந்த data directory-ன் உரிமை root வசம் இருக்கும், ஆனால் app uid 1000-ஆக இயங்கும். அதனால் database file-ஐத் திறக்க முடியாது. host directory-க்கு sudo chown -R 1000:1000 செய்யவும்.

கோரிக்கைகள் HTTP 429 மூலம் பதிலளிக்கப்படுகின்றன. /api/track மற்றும் /go/<id>-ல் உள்ள per-IP throttle வரம்பை எட்டிவிட்டது. பார்வையாளர்கள் இன்னும் தங்கள் இலக்குக்குத் திருப்பி விடப்படுகிறார்கள், அந்த click மட்டும் கணக்கிடப்படுவதில்லை.

FAQ

LinkBreeze பொதுவான link in bio பயன்பாட்டிற்குத் தயாரா?

இது ஒரு புதிய project. ஆகஸ்ட் 2026 நிலவரப்படி, இந்த repository 178 stars, 17 forks மற்றும் ஒரு maintainer-ஐக் கொண்டுள்ளது. இதன் முதல் release ஜூலை 1, 2026 அன்று வெளியிடப்பட்டது. சராசரியாக வாரத்திற்கு இரண்டு முறைக்கும் மேலாக releases வருவதால், பிழைகள் விரைவாகச் சரிசெய்யப்படுகின்றன, அதே சமயம் செயல்பாடுகளும் வேகமாக மாறுகின்றன. MIT license மற்றும் local SQLite file இருப்பதால், development நின்றாலும் உங்களால் தொடர்ந்து பக்கத்தைப் பயன்படுத்த முடியும். இருப்பினும், security updates இல்லாத public web app ஒரு சுமையாக மாறக்கூடும் என்பதால், இதை ஒருமுறை நிறுவிவிட்டு மறக்கும் மென்பொருளாகக் கருதாமல், தொடர்ந்து update செய்யும் மென்பொருளாகக் கருதவும்.

நான் எந்த LinkBreeze image tag-ஐப் பயன்படுத்த வேண்டும்?

version tag-ஐப் பயன்படுத்தவும், உதாரணமாக ghcr.io/manak-hash/linkbreeze:1.2.7. இதைத் திட்டமிட்டு மாற்றவும். release workflow latest மற்றும் version எண்ணை மட்டுமே push செய்கிறது. எனவே, v உடன் கூடிய :v1.2.7 கிடையாது; அவ்வாறு தேடினால் Docker manifest unknown என்று பதிலளிக்கும். இந்த image linux/amd64-க்கு மட்டுமே உருவாக்கப்பட்டுள்ளது. எனவே, arm64 VPS-ல் இதைப் பயன்படுத்த விரும்பினால், tag-ஐ clone செய்து உள்ளூர் அளவில் build செய்ய வேண்டும்.

LinkBreeze analytics-ல் ஏன் நாட்டின் விவரங்கள் (country breakdown) காலியாக உள்ளன?

LinkBreeze பார்வையாளர்களின் நாட்டை cf-ipcountry அல்லது x-vercel-ip-country போன்ற proxy headers மூலம் கண்டறிகிறது. இதற்கெனத் தனியாக GeoIP database இல்லை. உங்கள் Caddy அல்லது Nginx-க்கு பின்னால் உள்ள VPS-ல் இந்த headers அமைக்கப்படவில்லை என்றால், நாட்டின் விவரம் null என்று சேமிக்கப்படும். உங்கள் domain-க்கு முன்னால் Cloudflare-ஐப் பயன்படுத்தவும் அல்லது உங்கள் reverse proxy மூலம் local GeoIP lookup செய்து அந்த headers-ஐ அமைக்கவும்.

நான் எதை backup எடுக்க வேண்டும், அதை எப்படி restore செய்வது?

database file-ஐ மட்டும் எடுக்காமல், முழு linkbreeze-data volume-ஐயும் backup எடுக்கவும். /app/data/linkbreeze.db-ல் அனைத்து links, page, settings, subscribers மற்றும் analytics விவரங்களும் உள்ளன. /app/data/uploads-ல் அந்தப் பக்கம் குறிப்பிடும் avatar மற்றும் thumbnail படங்கள் உள்ளன. container-ஐ நிறுத்திவிட்டு, docker compose cp linkbreeze:/app/data ./backup-$(date +%F) கட்டளையை இயக்கவும், பிறகு மீண்டும் தொடங்கவும். container நிறுத்தப்பட்ட நிலையில், அந்த directory-ஐ மீண்டும் நகலெடுத்து, container-ஐத் தொடங்குவதன் மூலம் restore செய்யலாம். dashboard-லிருந்து எடுக்கப்படும் JSON export என்பது profile, links, settings மற்றும் themes ஆகியவற்றின் config snapshot மட்டுமே; இதில் analytics அல்லது படங்கள் இருக்காது.

Linktree-லிருந்து import செய்யும்போது எனது analytics மற்றும் theme வருமா?

வராது. migration wizard உங்கள் பழைய public profile-லிருந்து link titles, URLs, descriptions, images, display name, bio மற்றும் avatar ஆகியவற்றை மட்டுமே படிக்கும். analytics history, theme, email subscribers மற்றும் scheduled publish dates ஆகியவை பழைய தளத்திலேயே தங்கிவிடும். import செய்த பிறகு theme editor-ல் தோற்றத்தை மீண்டும் உருவாக்கவும். உங்கள் click history பழைய தளத்திலேயே இருக்கும் என்பதை நினைவில் கொள்ளவும்.