द्वारे BookStack, Wiki.js की Outline: योग्य self-hosted wiki
BookStack, Wiki.js आणि Outline यांची setup, संपादन पद्धत, login पर्याय व search यांवर तुलना. एकट्या admin साठी आणि टीमसाठी योग्य निवड स्पष्ट केली आहे.
कोणता self-hosted wiki चालवावा
self-hosted wiki मुळे तुमच्या टीमची कागदपत्रे तुम्ही नियंत्रित करत असलेल्या सर्व्हरवरील एका शोधता येण्याजोग्या ठिकाणी ठेवता येतात. BookStack, Wiki.js आणि Outline ही तिन्ही उत्पादने हे काम करतात. पहिले पेज लोड होण्यापूर्वी तुम्हाला किती गोष्टी एकत्र configure कराव्या लागतात आणि कोणाला login करण्याची परवानगी आहे, या बाबतीत त्यांच्यात सर्वाधिक फरक आहे.
BookStack उभारणे सर्वात सोपे आहे आणि त्याची रचना सर्वाधिक ठरावीक आहे. Wiki.js एका page tree साठी editors ची सर्वात मोठी निवड देते. या तिन्हींपैकी Outline मध्ये लेखनाचा अनुभव सर्वोत्तम आहे. तसेच बाहेरील identity provider जोडल्याशिवाय ते कोणालाही sign in करू देत नाही.
खालील सर्व माहिती संबंधित projects च्या स्वतःच्या documentation आणि प्रकाशित configuration files मधून घेतली आहे. ही benchmark नसून capabilities ची तुलना आहे. तिन्ही projects मध्ये सतत बदल होत असल्यामुळे version numbers आणि requirements यांना तारीख दिली आहे.
रचना हाच खरा पर्याय
BookStack तुमच्या सामग्रीची रचना निश्चित करते. एखादे पृष्ठ पुस्तकामध्ये असते, पुस्तकामध्ये प्रकरणे असू शकतात आणि shelves मध्ये पुस्तके गटबद्ध केली जातात. तुम्ही पाचवा स्तर तयार करू शकत नाही. हीच या उत्पादनाची मर्यादा त्याची उपयुक्तता ठरते: नवीन लेखकाला एखादे पृष्ठ कुठे ठेवायचे हे माहीत असते, कारण ते ठेवण्यासाठी एकच जागा असते. मात्र, या रचनेत न बसणाऱ्या सामग्रीला त्यात जबरदस्तीने बसवावे लागते.
Wiki.js डिस्कवरील folders प्रमाणे path tree वापरते. ops/backup/restic वरील पृष्ठ तुम्ही जिथे ठेवता तिथे असते आणि त्याची खोली तुम्ही ठरवता. दोन व्यक्तींना एकाच विषयाची नोंद दोन वेगवेगळ्या branches मध्ये करण्यापासून काहीही रोखत नाही. त्यामुळे Wiki.js instance साठी tree ची जबाबदारी घेणारी एक व्यक्ती आवश्यक असते.
Outline मध्ये collections वापरली जातात आणि documents इतर documents मध्ये nested असतात. एखादा document mouse ने drag करून हलवता येतो. या तीन पर्यायांपैकी हे सर्वात लवचिक आहे. त्यामुळे त्याची रचना हळूहळू विस्कळीत होणेही सर्वात सोपे आहे.
BookStack: सर्वांत लहान स्थापना
BookStack हे MySQL वर चालणारे PHP अॅप्लिकेशन आहे. July 2026 पर्यंत दस्तऐवजीकरणानुसार आवश्यक आवृत्ती PHP 8.2 किंवा त्यानंतरची आहे. तसेच MySQL 8.0 किंवा MariaDB 10.6 किंवा त्यानंतरची आवृत्ती आवश्यक आहे. source मधून स्थापना करत असल्यास Composer 2.2 किंवा त्यानंतरची आवृत्तीही आवश्यक आहे. सध्याची release line 26.05 आहे.
प्रकल्प प्रत्येक Ubuntu release साठी एक installation script प्रकाशित करतो. 24.04 script तुमच्यासाठी Apache, MySQL 8.0 आणि PHP 8.3 स्थापित करते.
wget https://codeberg.org/bookstack/devops/raw/branch/main/scripts/installation-ubuntu-24.04.sh
chmod a+x installation-ubuntu-24.04.sh
sudo ./installation-ubuntu-24.04.shतो script चालवण्यापूर्वी त्यावरील warning वाचा. दस्तऐवजीकरणात स्पष्टपणे नमूद केले आहे: "ONLY FOR A FRESH OS, it will install Apache, MySQL 8.0 & PHP 8.3 and could OVERWRITE any existing web setup on the machine". ज्या सर्व्हरवर port 80 वर आधीच विनंत्यांना उत्तर दिले जाते, तेथे हा script तो port ताब्यात घेतो आणि Apache configuration पुन्हा लिहितो. अशा सर्व्हरवर containers वापरा. किंवा Ubuntu 24.04 वरील विद्यमान LAMP stack वर BookStack हाताने स्थापित करा.
Container पद्धतीत LinuxServer.io image वापरली जाते. BookStack दस्तऐवजीकरणात याच पर्यायाकडे निर्देश केला आहे. BookStack ला session encryption key आवश्यक असते. ती नसल्यास ते pages देत नाही. त्यामुळे प्रथम ती generate करा.
docker run -it --rm --entrypoint /bin/bash lscr.io/linuxserver/bookstack:latest appkeyछापलेली value APP_KEY मध्ये copy करा. त्यानंतर service लिहा:
services:
bookstack:
image: lscr.io/linuxserver/bookstack:latest
container_name: bookstack
environment:
- PUID=1000
- PGID=1000
- TZ=Etc/UTC
- APP_URL=https://wiki.example.com
- APP_KEY=paste_the_generated_key_here
- DB_HOST=bookstack_db
- DB_PORT=3306
- DB_USERNAME=bookstack
- DB_PASSWORD=change_me
- DB_DATABASE=bookstackapp
volumes:
- ./config:/config
ports:
- 6875:80
restart: unless-stoppedAPP_URL मध्ये readers प्रत्यक्ष टाइप करतात तो address असणे आवश्यक आहे. त्यात scheme आणि कोणताही port यांचा समावेश असावा. ते http://localhost वर सेट करून site HTTPS वर serve करा. अन्यथा generated links आणि redirects चुकीच्या host कडे निर्देश करतील. Readers ना हे login page स्वतःकडेच पुन्हा redirect होत असल्यासारखे दिसेल. compose files तुमच्यासाठी नवीन असल्यास, या tutorial पूर्वी VPS वरील Docker Compose ची मूलतत्त्वे वाचा.
Application ला उत्तर मिळते आहे का ते तपासा. फक्त container चालू आहे का ते पाहू नका:
docker compose up -d
docker compose ps
curl -sI http://127.0.0.1:6875/login200 OK याचा अर्थ PHP application boot झाली आणि database पर्यंत पोहोचली. 500 याचा अर्थ जवळजवळ नेहमी APP_KEY रिकामे आहे किंवा database credentials जुळत नाहीत. docker compose logs bookstack यापैकी नेमके कोणते कारण आहे ते दाखवते.
Wiki.js: एक ट्री, अनेक संपादक
Wiki.js हे Node.js अॅप्लिकेशन आहे. दस्तऐवजीकरणातील Docker सेटअपमध्ये ते PostgreSQL सोबत वापरले जाते. मात्र हे सॉफ्टवेअर MySQL, MariaDB, MSSQL आणि SQLite देखील स्वीकारते. प्रकल्पाच्या स्वतःच्या Docker पृष्ठावरील compose फाइल अशी आहे:
services:
db:
image: postgres:15-alpine
environment:
POSTGRES_DB: wiki
POSTGRES_PASSWORD: wikijsrocks
POSTGRES_USER: wikijs
logging:
driver: none
restart: unless-stopped
volumes:
- db-data:/var/lib/postgresql/data
wiki:
image: ghcr.io/requarks/wiki:2
depends_on:
- db
init: true
environment:
DB_TYPE: postgres
DB_HOST: db
DB_PORT: 5432
DB_USER: wikijs
DB_PASS: wikijsrocks
DB_NAME: wiki
restart: unless-stopped
ports:
- "80:3000"
volumes:
db-data:ते चालवण्यापूर्वी POSTGRES_PASSWORD आणि DB_PASS एकत्र बदला, कारण ते एकाच credential चे भाग आहेत आणि नमुना मूल्य सार्वजनिक आहे. tag ghcr.io/requarks/wiki:2 वर स्थिर ठेवण्यामागे कारण आहे. latest टाळण्याची शिफारस दस्तऐवजीकरणात केली आहे, कारण major version बदलल्यास चालू instance अंतर्गत database schema बदलतो.
चालवण्यासाठी Version 2 हीच आवृत्ती वापरा. July 2026 पर्यंत Version 2 ची नवीनतम release 2.5.314 आहे; ती May 2026 मध्ये प्रसिद्ध झाली. Version 3 उपलब्ध आहे. तिच्या दस्तऐवजीकरणात असे म्हटले आहे: "हे संकेतस्थळ Wiki.js 3.0 च्या अस्थिर beta release साठी आहे. हे production मध्ये install करू नये." :3 tag ला preview समजा.
पहिल्यांदा लोड केल्यावर Wiki.js browser मधील setup प्रक्रियेद्वारे administrator account तयार करून घेते. ती प्रक्रिया पूर्ण होईपर्यंत port पर्यंत पोहोचणाऱ्या कोणालाही तो wizard दिसतो. त्यामुळे firewall उघडण्यापूर्वी सेवा reverse proxy आणि TLS (transport layer security) मागे ठेवा. सर्व्हरवर या एकापेक्षा अधिक सेवा असतील, तर स्वतंत्र hostname वरचा wiki अनेक Docker अॅप्ससमोर Traefik मागे ठेवणे स्वाभाविक ठरते.
लोक Wiki.js निवडण्यामागे editor ची निवड हे एक कारण आहे. एकाच instance मध्ये Markdown pages, visual editor pages, raw HTML pages आणि AsciiDoc pages एकत्र ठेवता येतात. रूपांतर न करण्यास प्राधान्य असलेल्या जुन्या content चे import करताना हे उपयुक्त ठरते. मात्र त्यामुळे एका wiki मध्ये चार वेगवेगळ्या house styles तयार होऊ शकतात. म्हणून पहिल्याच दिवशी default editor ठरवा आणि तो निर्णय नोंदवून ठेवा.
Outline: सर्वोत्तम editor, सर्वाधिक prerequisites
लोकांना commercial notes tool सारखा अनुभव देणारे काहीतरी हवे आहे असे म्हणताना, सामान्यतः त्यांचा अर्थ Outline असा असतो. हे Node.js application आहे आणि July 2026 पर्यंतची current release 1.9.2 आहे. त्याच्या sample environment file मध्ये आवश्यक गोष्टी दिल्या आहेत: DATABASE_URL द्वारे PostgreSQL, REDIS_URL द्वारे Redis, दोन random secrets आणि publicly reachable URL.
openssl rand -hex 32
openssl rand -hex 32ही command दोनदा चालवा आणि दोन्ही values जतन करा. पहिली value SECRET_KEY आणि दुसरी UTILS_SECRET बनेल. Environment file चा मुख्य भाग असा दिसतो:
NODE_ENV=production
URL=https://docs.example.com
PORT=3000
SECRET_KEY=<first openssl value>
UTILS_SECRET=<second openssl value>
DATABASE_URL=postgres://outline:change_me@postgres:5432/outline
PGSSLMODE=disable
REDIS_URL=redis://redis:6379
FILE_STORAGE=local
FILE_STORAGE_LOCAL_ROOT_DIR=/var/lib/outline/dataDatabase त्याच machine वर किंवा त्याच Docker network वर असेल तेव्हाच PGSSLMODE=disable योग्य आहे. Network वरून database शी connection करत असल्यास ते वगळा; अन्यथा connection encrypted नसते. Attachments साठी आता object storage आवश्यक नाही: FILE_STORAGE=local uploads वर दिलेल्या directory मध्ये लिहिते. ही directory container ला write करता येईल असा volume असला पाहिजे आणि तुमच्या backups मध्ये समाविष्ट असली पाहिजे. Files S3 compatible bucket मध्ये ठेवायच्या असल्यास AWS_* values वापरून FILE_STORAGE=s3 सेट करा.
आता लोकांना आश्चर्य वाटणारा भाग. Outline मध्ये username आणि password login अंगभूत नाही. त्याच्या sample configuration नुसार third-party sign-in credentials आवश्यक आहेत: "working installation साठी यांपैकी किमान ONE आवश्यक आहे; अन्यथा sign-in चे कोणतेही पर्याय उपलब्ध राहणार नाहीत". Document केलेल्या providers मध्ये Google, Slack, Microsoft Entra, Discord आणि OIDC_CLIENT_ID, OIDC_CLIENT_SECRET, OIDC_AUTH_URI, OIDC_TOKEN_URI आणि OIDC_USERINFO_URI द्वारे कोणताही generic OpenID Connect (OIDC) server समाविष्ट आहे.
म्हणून Outline ची वास्तविक किंमत म्हणजे Outline, PostgreSQL, Redis आणि identity provider. तुमची team आधीच Google Workspace किंवा Microsoft Entra वापरून sign in करत असल्यास, शेवटचा भाग setup करण्यासाठी दहा मिनिटे लागतात आणि Outline अतिशय उपयुक्त ठरते. तसे नसल्यास, तुम्हाला Keycloak किंवा Authentik सारखी service देखील self-host करावी लागेल. ती patch आणि backup करण्यासाठी आणखी एक service ठरते. Memory चे budget त्यानुसार ठेवा: Outline च्या मार्गदर्शनानुसार प्रत्येक web process साठी अंदाजे 512 MB memory आवश्यक असते. हे WEB_CONCURRENCY द्वारे सेट केले जाते आणि database व Redis साठी लागणाऱ्या memory व्यतिरिक्त असते.
प्रत्येक प्रणाली कोणाला काय वाचता येईल हे कसे ठरवते
BookStack मध्ये सुरुवातीपासूनच स्थानिक email आणि password खाती उपलब्ध असतात. पर्याय म्हणून ते LDAP, SAML2 आणि OIDC ला समर्थन देते. परवानग्या प्रत्येक role साठी सेट करता येतात. त्या एकाच shelf, book, chapter किंवा page वर बदलता येतात. hierarchy निश्चित असल्यामुळे परवानग्या तिच्या खालच्या स्तरांवर अंदाज करता येईल अशा पद्धतीने लागू होतात.
Wiki.js मध्येही स्थानिक खाती उपलब्ध असतात. याशिवाय admin area मधून enable करता येणाऱ्या अनेक strategies ते देते. त्याचे page rules path pattern नुसार प्रवेश मंजूर किंवा नाकारतात. ही पद्धत सामर्थ्यवान आहे; परंतु चुकणे सोपे आहे. कारण ops/* साठी लिहिलेला rule नंतर त्या path अंतर्गत ठेवलेल्या प्रत्येक page वर शांतपणे लागू होतो.
Outline हा प्रश्न पूर्णपणे identity provider कडे सोपवते. Membership तुमच्या identity provider नुसार ठरते. Outline मध्ये तुम्ही collection आणि group नुसार access नियंत्रित करता. एखादी व्यक्ती कंपनी सोडल्यानंतर तिचे कोणतेही local account शिल्लक राहत नाही. identity provider मधून deprovisioning करत असल्यास हा महत्त्वाचा फायदा आहे.
प्रत्येकामध्ये शोध कसा कार्य करतो
शोधामुळे wiki उपयुक्त ठरते किंवा विसरलेल्या फाइल्सच्या फोल्डरमध्ये रूपांतरित होते.
BookStack डेटाबेसमध्ये शोध घेते आणि वाचकांना एका मिनिटात शिकता येईल अशी query language देते. "london meeting" प्रमाणे एखादा phrase उद्धरणचिन्हांत दिल्यास तोच अचूक string आवश्यक असतो. Square brackets tags मध्ये शोध घेतात: [location=london] हे tag name, value किंवा दोन्हींनुसार जुळते. यामध्ये !=, >= आणि like यांसारख्या तुलना समाविष्ट आहेत. Curly braces metadata वर filter लावतात, जसे {created_after:2016-12-30} मध्ये. कोणत्याही exact, tag किंवा filter term च्या सुरुवातीला - लावल्यास तो term वगळला जातो. BookStack एका query मध्ये प्रत्येक प्रकारचे किती terms असू शकतात यावर मर्यादा घालते. त्यामुळे अतिशय मोठी query चालवण्याऐवजी ती छाटली जाते.
Wiki.js मध्ये शोध हा pluggable module म्हणून काम करतो. दस्तऐवजीकरण केलेली engines म्हणजे basic database engine, PostgreSQL engine, Elasticsearch, Algolia, AWS CloudSearch आणि Azure Search. काहीशे pages साठी basic engine पुरेसे आहे. PostgreSQL वापरत असल्यास admin area मध्ये PostgreSQL engine निवडा. कारण ते simple matching ऐवजी database चा स्वतःचा full text index वापरते. दुसरी search service चालवणे आणि तिचे patches लागू करणे स्वीकार्य असेल, इतकी wiki मोठी असल्यासच Elasticsearch वापरा.
Outline PostgreSQL full text indexes मध्ये शोध घेते. Engine निवडण्याची किंवा कोणतीही setting बदलण्याची गरज नसते. तसेच uploaded documents मधील text मध्येही शोध घेतला जातो. काही हजार documents असलेल्या team wiki साठी या तिन्हींपैकी यात सर्वात कमी व्यवस्थापन आवश्यक असते. कामगिरी कधी पुरेशी राहिली नाही, तरी ती सुधारण्यासाठी बदलण्यासारखी कोणतीही setting उपलब्ध नाही.
तुमच्यासाठी योग्य पर्याय कोणता
आज दुपारपर्यंत wiki सुरू हवी असेल आणि रचनेपेक्षा मजकुरावर चर्चा करणे पसंत असेल, तर BookStack निवडा. यामध्ये सर्वात कमी घटक आहेत: एक PHP application आणि एक MySQL database. अंतर्गत runbook आणि ग्राहकांसाठीचे documentation यासाठी ते योग्य आहे. बहुतेक लेखक engineers नसलेल्या teams साठीही ते योग्य ठरते. या तीन पर्यायांपैकी त्याचा backup घेणे सर्वात सोपे आहे, कारण संपूर्ण state मध्ये एक database dump आणि uploads directory एवढेच असते.
इतर पर्यायांमध्ये उपलब्ध नसलेला विशिष्ट editor किंवा विशिष्ट authentication strategy आवश्यक असेल, किंवा मोठ्या प्रमाणातील विद्यमान Markdown किंवा AsciiDoc import करून path structure जशीच्या तशी ठेवायची असेल, तर Wiki.js निवडा. मात्र यासाठी अधिक जड stack चालवावा लागेल, हे लक्षात घ्या आणि major version tag निश्चित करा.
लेखनाची गुणवत्ता सर्वात महत्त्वाची असेल, wiki सार्वजनिक वापरासाठी नसून team साठी असेल आणि तुमच्याकडे आधीपासून identity provider असेल, तर Outline निवडा. या setup मुळे वापरकर्त्यांना प्रत्यक्षात वापरायला आवडणारा editor मिळतो. मात्र हे तुमचे पहिले self-hosted application म्हणून निवडू नका.
यापैकी एकही पर्याय योग्य नसेल, तर समस्या सहसा content type मध्ये असते. Scanned invoices आणि contracts यांसाठी wiki ऐवजी Paperless-ngx सारखी document management system वापरा. त्यांना wiki मध्ये जबरदस्तीने बसवणे हे अनेक wikis शेवटी वापरात न राहण्याचे कारण असते. दुसरी सामान्य विसंगती म्हणजे wiki ऐवजी workspace आवश्यक असणे. एकाच canvas वर documents, tables आणि whiteboard हवे असल्यास self-hosted AFFiNE workspace वरील तीनही पर्यायांपेक्षा अधिक योग्य ठरते. तुमच्या स्वतःच्या server वर आणखी कोणत्या सेवा ठेवण्यासारख्या आहेत, याचा व्यापक आढावा घेण्यासाठी 2026 साठीची self-hosting shortlist पहा.
आकारमान आणि बॅकअप
हे तिन्ही लहान VPS वर चालू शकतात. मात्र प्रत्येकाच्या मागे असलेल्या घटकांनुसार आवश्यक किमान संसाधने वेगळी असतात. BookStack मध्ये एक application process आणि MySQL असते. Wiki.js मध्ये Node process आणि PostgreSQL असते. Outline मध्ये Node process, PostgreSQL आणि Redis असतात. सहसा त्यासोबत identity provider देखील असतो. त्यामुळे Outline साठी अधिक memory द्यावी.
Database आणि uploads यांचा एकत्रित बॅकअप घ्या. त्या बॅकअपवर अवलंबून राहण्यापूर्वी तो एखाद्या तात्पुरत्या instance मध्ये एकदा restore करून पाहा. ज्याचा restore करून पाहिलेला नाही, असा wiki बॅकअप केवळ अंदाज असतो. BookStack साठी याचा अर्थ mysqldump आणि /config volume असा होतो. Wiki.js आणि Outline साठी pg_dump आणि data volume आवश्यक असतात. Outline साठी FILE_STORAGE_LOCAL_ROOT_DIR मध्ये असलेल्या घटकांचाही बॅकअप घ्यावा.
FAQ
कोणता self-hosted wiki स्थापित करणे सर्वात सोपे आहे?
BookStack. हा MySQL database वापरणारा एकच PHP अॅप्लिकेशन आहे. Ubuntu 24.04 साठी प्रकल्प installation script देतो. ती एका रनमध्ये Apache, MySQL 8.0 आणि PHP 8.3 सेट करते. Container image साठी फक्त APP_KEY आणि database credentials आवश्यक आहेत. Wiki.js मध्ये Node runtime आणि PostgreSQL server अतिरिक्त आवश्यक असतात. Outline मध्ये त्यावर Redis आणि बाह्य identity provider देखील आवश्यक असतो.
Google किंवा अन्य SSO provider शिवाय Outline वापरता येईल का?
नाही. Outline मध्ये स्थानिक username आणि password login नाही. त्याच्या sample configuration नुसार किमान एक third-party sign-in provider आवश्यक आहे. अन्यथा sign-in साठी कोणताही पर्याय उपलब्ध राहत नाही. तुम्ही Google, Slack, Microsoft Entra, Discord किंवा self-hosted Keycloak किंवा Authentik सारखा कोणताही generic OpenID Connect server वापरू शकता. Outline चालवण्याच्या खर्चात त्या provider चे संचालनही समाविष्ट असते.
Wiki.js 3 स्थापित करावे की Wiki.js 2?
Version 2. July 2026 पर्यंत version 2 ची नवीनतम release 2.5.314 आहे. ती May 2026 मध्ये प्रसिद्ध झाली. Version 3 च्या documentation मध्ये स्पष्टपणे सांगितले आहे की ते unstable beta आहे आणि production मध्ये स्थापित करू नये. तुमची image ghcr.io/requarks/wiki:2 वर pin करा, latest वर नाही. कारण major version बदलल्यास सुरू असलेल्या instance अंतर्गत database schema बदलते.
यापैकी कोणाची search सुविधा सर्वात चांगली आहे?
प्रत्येकाची क्षमता वेगवेगळ्या प्रकारे चांगली आहे. BookStack वाचकांना exact phrases साठी query language, [location=london] सारखे tag filters आणि {created_after:2016-12-30} सारखे metadata filters देते. या terms पैकी कोणताही term सुरुवातीला - लावून वगळता येतो. Outline साठी configuration आवश्यक नाही. ते uploaded files मधील text शोधते. Wiki.js सर्वाधिक tunable आहे, कारण engine तुम्ही निवडता. तुमचा wiki काही hundred pages पेक्षा मोठा झाल्यावर PostgreSQL engine वर switch करणे उपयुक्त ठरते.
नंतर एका wiki मधून दुसऱ्या wiki मध्ये माझा content हलवता येईल का?
काही अंशी, परंतु manual काम करावे लागेल अशी अपेक्षा ठेवा. तिन्ही अॅप्स Markdown export आणि import करतात. त्यामुळे page text सहसा टिकून राहतो. मात्र structure व्यवस्थित टिकत नाही. BookStack मधील books आणि chapters यांना Outline मधील nested documents मध्ये समतुल्य रचना नाही. Wiki.js paths चे BookStack मधील fixed hierarchy शी mapping होत नाही. Attachments, permissions आणि page history हे नष्ट होण्याची सर्वाधिक शक्यता असलेले भाग आहेत. त्यामुळे migration निश्चित करण्यापूर्वी sample export करा आणि हे भाग तपासा.