SSD Nodes Learn 🎉 VPS $5.50/महिन्यापासून
मार्गदर्शक Matt Connorद्वारे Matt Connor

VPS वर rootless Podman मध्ये Ollama कसे चालवावे

स्वतंत्र unprivileged user, lingering आणि reboot नंतर सुरू होणारी Quadlet unit वापरून Ollama चालवा. SELinux labels योग्य ठेवा आणि port 11434 फक्त loopback वर बंद ठेवा.

VPS वरील rootless Podman मध्ये Ollama चालवा

सर्व्हरवर rootless Podman मध्ये Ollama चालवण्यासाठी desktop walkthrough मध्ये वगळता येतील अशा पाच गोष्टी आवश्यक आहेत. कंटेनरचा मालक स्वतंत्र unprivileged user असतो. त्या user साठी lingering सक्षम केलेले असते, त्यामुळे तुम्ही logout केल्यानंतरही कंटेनर चालू राहतो. Quadlet file कंटेनर systemd कडे सोपवते, त्यामुळे reboot नंतर तो पुन्हा सुरू होतो. SELinux लागू करणाऱ्या distributions वर model directory ला योग्य SELinux label दिलेले असते. API फक्त loopback वर listening करते आणि तुम्ही त्यापर्यंत SSH (secure shell) tunnel द्वारे पोहोचता.

Ollama हा large language models (LLM) साठी server आहे. तो model weights disk वर साठवतो, ते memory मध्ये load करतो आणि port 11434 वरील HTTP requests ला उत्तरे देतो. त्यामध्ये login, API key किंवा user accounts नाहीत. त्यामुळे तुम्हाला मिळणारे एकमेव access control म्हणजे network. Podman daemon शिवाय आणि root शिवाय containers चालवतो. त्यामुळे container मधून काही बाहेर पडले तरी ते सुरुवातीला सामान्य unprivileged user म्हणूनच चालते. Runtime comparison आधी पाहायची असल्यास VPS वर Podman आणि Docker यांच्यातील फरक वाचा. Containers पूर्णपणे टाळायचे असल्यास VPS वर Ollama थेट install करणे हा अधिक छोटा मार्ग आहे.

SSD Nodes आपल्या images मध्ये Fedora उपलब्ध करून देते. Fedora मध्ये Podman आणि SELinux (security-enhanced Linux) default म्हणून दोन्ही उपलब्ध असतात. खालील प्रत्येक command Podman 5 किंवा त्याहून नवीन आवृत्ती असलेल्या कोणत्याही distribution वर चालतो.

सर्व्हरसाठी laptop आवृत्तीत बदल का आवश्यक आहेत

Fedora Magazine ने 5 August 2026 रोजी या stack चे स्पष्ट मार्गदर्शन प्रकाशित केले: Fedora Linux वर Podman वापरून Ollama स्थानिक पातळीवर चालवणे, Yazan Monshed यांनी लिहिलेले. या tools सोबत सुरुवात करण्यासाठी ते उपयुक्त आहे. मात्र ते laptop लक्षात घेऊन तयार केलेले आहे. सार्वजनिक IP address असलेल्या मशीनवर त्यातील चार निवडी वेगळ्या प्रकारे कार्य करतात.

  • ते container साध्या podman run -d ने सुरू करते. हाताने सुरू केलेला container reboot नंतर पुन्हा सुरू होत नाही, कारण तो सुरू करण्याची कोणतीही व्यवस्था केलेली नसते.
  • ते बदलत राहणारा ollama/ollama tag वापरते. laptop वर वर्तन बदललेला दिवस तुमच्या लक्षात येतो. server वर पहिला संकेत म्हणजे एखादी script रातोरात काम करणे थांबवते.
  • ते -p 11434:11434 वापरून publish करते. त्यामुळे ते प्रत्येक interface वर bind होते. home router मागे असताना ते internet वरून पोहोचण्यायोग्य नसते. VPS वर मात्र ते password नसलेले public inference API बनते.
  • ते तुमच्या स्वतःच्या login user अंतर्गत चालते. server वर container च्या मालकीचे account इतर कोणत्याही वस्तूचे मालक नसावे. त्यामुळे break-out झाल्यास प्रवेश रिकाम्या home directory मध्ये होतो.

ज्या मशीनसाठी हे लिखाण केले आहे, त्या मशीनसाठी यापैकी काहीही चुकीचे नाही. मात्र box सर्व ठिकाणांहून पोहोचण्यायोग्य असतो आणि त्याच्यासमोर कोणी बसलेले नसते, तेव्हा प्रत्येक बाबीचा पुन्हा विचार करावा लागतो.

अविशेषाधिकारित user तयार करा आणि subuid तपासा

Rootless Podman कंटेनरमधील अंतर्गत user IDs (UID) host वरील न वापरलेल्या IDs च्या एका block वर map करतो. हा block /etc/subuid आणि /etc/subgid मध्ये घोषित केला जातो. हा block नसल्यास rootless containers सुरूच होऊ शकत नाहीत.

sudo dnf install -y podman        # or: sudo apt install -y podman
sudo useradd --create-home --shell /bin/bash --comment "Ollama container owner" ollama
sudo passwd --lock ollama
grep ollama /etc/subuid /etc/subgid

grep ने दोन lines दाखवाव्यात. प्रत्येक file मधून एक line असावी आणि प्रत्येक line मध्ये 65536 IDs ची range असावी:

/etc/subuid:ollama:100000:65536
/etc/subgid:ollama:100000:65536

तुमचा starting number वेगळा असेल. ते योग्य आहे. grep ने काहीही दाखवले नाही, तर useradd ने range allocate केलेली नाही. त्यामुळे त्या user म्हणून चालवलेला पहिला podman command अशा प्रकारे fail होतो:

Error: cannot find UID/GID for user ollama: no subuid ranges found for user "ollama" in /etc/subuid

इतर कोणत्याही user कडे नसलेली range assign करा. त्यानंतर Podman ला त्याचे जुने mapping stale असल्याचे कळवा:

sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 ollama
sudo -iu ollama podman system migrate

Password lock केल्याने कोणीही ollama म्हणून थेट login करू शकत नाही. तुमच्या admin user कडून sudo -iu ollama वापरून या account मध्ये प्रवेश करा.

लॉगआउटनंतर सेवा सुरू ठेवण्यासाठी lingering सक्षम करा

वापरकर्त्याचा systemd instance सामान्यतः login वेळी सुरू होतो आणि logout वेळी थांबतो. त्याच्यासोबत /run/user/<uid> देखील काढून टाकले जाते. त्या वापरकर्त्याच्या मालकीचे प्रत्येक rootless container त्याच वेळी बंद होते. Lingering मुळे कोणतेही session जोडलेले नसतानाही वापरकर्त्याचा instance सुरू राहतो.

sudo loginctl enable-linger ollama
loginctl show-user ollama --property=Linger

यामुळे Linger=yes असे output दिसले पाहिजे. Unit तयार करण्यापूर्वी lingering सक्षम करा, कारण unit ला आवश्यक असलेली /run/user/<uid> directory lingering सुरू झाल्यावरच उपलब्ध होते.

यापुढे आणखी एक पायरी आवश्यक आहे. sudo -iu ollama तुम्हाला shell देते, पण session bus देत नाही. त्यामुळे systemctl --user लगेच अपयशी ठरते:

Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined

systemd वापरकर्ता bus साठी $XDG_RUNTIME_DIR/bus येथे शोधतो. sudo -i हा variable सेट करत नाही. ही सेवा व्यवस्थापित करताना वापरणाऱ्या प्रत्येक admin shell मध्ये तो manually सेट करा:

sudo -iu ollama
export XDG_RUNTIME_DIR=/run/user/$(id -u)
systemctl --user status

मॉडेल blobs कुठे साठवले जातात आणि डिस्कसाठी किती जागेचे नियोजन करावे

Ollama कंटेनरमध्ये /root/.ollama/models येथे weights लिहिते. त्या path वर वापरकर्त्याच्या home directory मधील एखादी directory bind करा. त्यामुळे files मोजता येतील अशा ठिकाणी साठवल्या जातात: /home/ollama/ollama-data/models. Blobs models/blobs येथे content-addressed files म्हणून साठवले जातात आणि models/manifests मध्ये त्यांची नावे असलेला छोटा index असतो. त्याऐवजी named volume वापरल्यास, Fedora Magazine च्या post मध्ये केल्याप्रमाणे, हाच tree /home/ollama/.local/share/containers/storage/volumes/<volume>/_data अंतर्गत साठवला जातो.

काहीही pull करण्यापूर्वी डिस्कची क्षमता ठरवा. प्रकाशित download sizes ही किमान आवश्यक क्षमतेची कल्पना देतात.

ChartPublished download size per Ollama model tag, ollama.com/library, checked 13 August 2026
The data behind this chart
[
  {
    "label": "gemma3:4b",
    "download_gb": 3.3
  },
  {
    "label": "mistral:7b",
    "download_gb": 4.4
  },
  {
    "label": "qwen3:8b",
    "download_gb": 5.2
  },
  {
    "label": "gemma3:12b",
    "download_gb": 8.1
  },
  {
    "label": "qwen3:14b",
    "download_gb": 9.3
  },
  {
    "label": "gemma3:27b",
    "download_gb": 17
  },
  {
    "label": "qwen3:30b",
    "download_gb": 19
  }
]

येथील सर्व 7 rows या ollama.com/library वर प्रकाशित केलेल्या आकडेवारीवर आधारित आहेत; त्या डिस्कवर मोजलेल्या sizes नाहीत. येथील सर्वात लहान tag gemma3:4b डाउनलोड करण्यासाठी 3.3 GB जागा घेतो. सर्वात मोठा tag qwen3:30b डाउनलोड करण्यासाठी 19 GB जागा घेतो. Container image त्याव्यतिरिक्त Podman च्या स्वतःच्या storage मध्ये साठवली जाते. त्यामुळे podman system df आणि df -h /home वापरून दोन्ही आकडे एकत्र तपासा. मॉडेल loaded असताना त्याला साधारणपणे त्याच्या file size एवढी RAM आणि context window साठी अतिरिक्त जागा आवश्यक असते. त्यामुळे 16 GB VPS वर 19 GB मॉडेल चालणार नाही.

इमेज tag निश्चित करा आणि पूर्ण registry name वापरा

sudo -iu ollama
export XDG_RUNTIME_DIR=/run/user/$(id -u)
mkdir -p ~/ollama-data ~/.config/containers/systemd
podman pull docker.io/ollama/ollama:0.32.9

प्रकाशित version tag वापरा; August 2026 पर्यंत 0.32.9 उपलब्ध आहे, latest नाही. निश्चित केलेल्या tag मुळे 04:00 वाजता restart केल्यावर तुम्ही तपासलेला तोच binary मिळतो. त्यामुळे वर्तनातील कोणताही बदल तुम्ही केलेला बदल असतो. Docker Hub त्याच versions साठी -rc आणि -rocm tags देखील प्रकाशित करते. तुमच्याकडे AMD GPU नसल्यास साधा tag निवडा.

registry host देखील लिहा. Fedora मध्ये systemd unit मधील short name ला prompt दाखवण्यासाठी terminal उपलब्ध नसतो. त्यामुळे unit खालील त्रुटीसह अयशस्वी होते:

Error: short-name "ollama/ollama" did not resolve to an alias and no unqualified-search registries are defined

आधी manually pull करणे ऐच्छिक आहे, पण उपयुक्त ठरते. त्यामुळे multi-gigabyte download unit च्या start timeout च्या बाहेर करता येतो.

रीबूटनंतरही टिकणारे Quadlet unit

Quadlet हा Podman चा systemd generator आहे. तुम्ही एक .container फाइल लिहिता, systemd boot वेळी तिला service मध्ये रूपांतरित करते आणि podman generate systemd ची यापुढे गरज राहत नाही. ही फाइल ollama user च्या मालकीची /home/ollama/.config/containers/systemd/ollama.container म्हणून जतन करा.

[Unit]
Description=Ollama API (rootless)
After=network-online.target
Wants=network-online.target

[Container]
Image=docker.io/ollama/ollama:0.32.9
ContainerName=ollama
PublishPort=127.0.0.1:11434:11434
Volume=/home/ollama/ollama-data:/root/.ollama:Z
Environment=OLLAMA_KEEP_ALIVE=30m
Environment=OLLAMA_MAX_LOADED_MODELS=1

[Service]
Restart=always
TimeoutStartSec=900

[Install]
WantedBy=default.target

फाइलचे नाव service चे नाव ठरवते. त्यामुळे ollama.container चे रूपांतर ollama.service मध्ये होते.

systemctl --user daemon-reload
systemctl --user start ollama.service
systemctl --user status ollama.service

status ने active (running) दाखवले पाहिजे. systemctl --user enable ollama.service चालवू नका. हे unit disk वर फाइल म्हणून अस्तित्वात नसते, त्यामुळे systemd ते नाकारते:

Failed to enable unit: Unit file /run/user/1001/systemd/generator/ollama.service is transient or generated.

[Install] section हे काम आधीच करते. Quadlet daemon-reload दरम्यान boot वेळी service सुरू करण्यासाठीची link स्वतः तयार करते. म्हणून ती command पर्यायी नाही. पहिल्यांदा सुरू करताना image pull करावा लागला, तरी TimeoutStartSec=900 पुरेसा वेळ देते. दोन gigabyte च्या download साठी default 90 seconds पुरेसे नसतात आणि systemd start ला failed म्हणून बंद करते. OLLAMA_KEEP_ALIVE=30m requests दरम्यान model memory मध्ये ठेवते, त्याऐवजी पाच minutes नंतर तो unload करत नाही. यातील तडजोडी Ollama model memory मध्ये loaded ठेवणे येथे दिल्या आहेत. येथे वापरलेली systemd संज्ञा नवीन असल्यास, VPS वर systemd services आणि timers कसे कार्य करतात येथे units विषयी माहिती दिली आहे.

SELinux अंतर्गत model directory साठी permission denied का दिसते

Fedora, RHEL, Rocky आणि AlmaLinux वर SELinux default ने enforcing मोडमध्ये असते. Container process container_t domain मध्ये चालतो, तर user च्या home मधील directory ला user_home_t label दिलेले असते. Policy एकाला दुसऱ्याला access करू देत नाही. त्यामुळे Ollama त्याची model tree तयार करू शकत नाही आणि container बंद होतो. या प्रणालींवर getenforce Enforcing दाखवते आणि denial नोंदवला जातो:

sudo ausearch -m avc -ts recent

तुम्हाला domain आणि target label नमूद करणारी ओळ दिसेल:

avc:  denied  { write } for  pid=1842 comm="ollama" name="models" dev="vda1" ino=131077 scontext=system_u:system_r:container_t:s0:c214,c827 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir permlisted=0

Volume= ओळीच्या शेवटी असलेले :Z हे याचे निराकरण आहे. ते host directory ला container_file_t label देते आणि तिला फक्त या container कडे असलेली private MCS (multi-category security) category लावते. याउलट lowercase :z shared label वापरते. दोन containers ने समान directory वाचायची असल्यास हेच वापरावे.

:Z बाबत एक महत्त्वाची सूचना आहे, कारण ते destructive आणि शांतपणे काम करते. Relabelling recursive असते. ते /home/ollama वर लागू केल्यास त्या home directory मधील प्रत्येक file ला पुन्हा label दिले जाते. त्यामुळे त्या user साठी SSH key access बंद होतो. :Z साठी नेहमी स्वतंत्र subdirectory द्या. त्या directory मध्ये इतर कोणतीही वस्तू ठेवू नका. Named volumes साठी हे आवश्यक नाही, कारण Podman ते तयार करताना योग्य labels लावते. अधिक माहिती हवी असल्यास server साठी SELinux मूलतत्त्वे येथे contexts आणि booleans यांचे स्पष्टीकरण आहे. Ubuntu आणि Debian वर त्याऐवजी AppArmor वापरले जाते. तेथे :Z निष्क्रिय असते. त्यामुळे unit मध्ये ते ठेवले तरी कोणतीही समस्या होत नाही.

11434 पोर्ट बंद करा आणि SSH द्वारे API वापरा

PublishPort=127.0.0.1:11434:11434 host-side ला loopback वर bind करते. ते पडताळा:

ss -ltnp | grep 11434
curl http://127.0.0.1:11434

ss च्या output मध्ये 127.0.0.1:11434 दिसले पाहिजे. 0.0.0.0:11434 किंवा *:11434 याचा अर्थ पोर्ट इंटरनेटसाठी उघडा आहे. तसेच curl ने Ollama is running ला उत्तर दिले पाहिजे.

तुम्ही कोणत्या बाजूला bind करत आहात, हे अचूकपणे तपासा. PublishPort मधील address हा host address आहे. Container मध्ये Ollama ने सर्व interfaces वर listening ठेवले पाहिजे. हे image चे default आहे. Environment=OLLAMA_HOST=127.0.0.1 सेट केल्यास Ollama container च्या स्वतःच्या loopback वर bind होते. त्याऐवजी Podman published traffic container च्या network address कडे forward करते. त्यामुळे host वरूनही प्रत्येक request नाकारली जाते.

11434 उघडा ठेवल्याने दोन समस्या निर्माण होतात. Ollama मध्ये authentication नाही. त्यामुळे पोर्टपर्यंत पोहोचणारा कोणीही /api/tags द्वारे तुमचे models list करू शकतो, /api/generate द्वारे तुमच्या CPU आणि bandwidth allowance चा वापर करून inference चालवू शकतो, तुमच्या disk वर नवीन models pull करू शकतो आणि उपलब्ध models delete करू शकतो. दुसरे म्हणजे, remote port कडे जाणारे plain HTTP prompts आणि completions cleartext मध्ये पाठवते. त्यामुळे मार्गातील प्रत्येक machine ते वाचू शकते. पोर्ट host च्या बाहेरच गेले नाही, तर या दोन्ही समस्या नाहीशा होतात.

तुमच्या workstation वरून SSH द्वारे पोर्ट forward करा:

ssh -N -L 11434:127.0.0.1:11434 you@vps.example.com

आता तुमच्या laptop वरील http://127.0.0.1:11434 हे SSH session च्या encryption मध्ये चालणारे server चे Ollama आहे. तुमच्या laptop वर Ollama आधीपासून चालू असल्यास local bind bind [127.0.0.1]:11434: Address already in use सह अयशस्वी होईल. -L 11435:127.0.0.1:11434 वापरा आणि तुमच्या client ला 11435 कडे निर्देशित करा.

Browser client ला हे आवश्यक असल्यास, त्यापुढे password असलेला reverse proxy ठेवा. Caddy site block चार ओळींचा असतो आणि caddy hash-password आवश्यक असलेला bcrypt hash दाखवते:

ollama.example.com {
  basic_auth {
    you $2a$14$replace_with_the_generated_hash
  }
  reverse_proxy 127.0.0.1:11434
}

Caddy स्वतः TLS (transport layer security) द्वारे certificate मिळवते. त्यामुळे traffic encrypted राहतो. प्रथम तुमचा client तपासा. Ollama शी संवाद साधणाऱ्या अनेक tools मध्ये Authorization header साठी field नसते. अशा tools मध्ये साध्या 401 Unauthorized सह basic auth अयशस्वी होते. SSH tunnel मध्ये ही समस्या नसते. म्हणून येथे SSH tunnel ची default शिफारस केली आहे.

मॉडेल pull करा आणि संपूर्ण मार्ग तपासा

podman exec -it ollama ollama pull gemma3:4b
curl -s http://127.0.0.1:11434/api/tags
curl -s http://127.0.0.1:11434/api/generate -d '{"model":"gemma3:4b","prompt":"Reply with the single word: ready","stream":false}'
du -sh ~/ollama-data/models

/api/tags gemma3:4b ची यादी असलेले JSON परत करते. /api/generate डिस्कवरून weights load होईपर्यंत थोडा विलंब झाल्यानंतर response field असलेला JSON object परत करते. du ने प्रकाशित download size च्या जवळपासची संख्या दाखवली पाहिजे. आता या संपूर्ण मार्गदर्शकाचा मुख्य उद्देश असलेला भाग सिद्ध करा:

sudo reboot
# reconnect, then:
sudo -iu ollama
export XDG_RUNTIME_DIR=/run/user/$(id -u)
systemctl --user is-active ollama.service

active म्हणजे प्रक्रिया अजूनही सुरू आहे; [Install] section आणि daemon-reload यांनी त्यांचे कार्य योग्य प्रकारे केले आहे. inactive म्हणजे या तिघांपैकी एक घटक अनुपस्थित आहे.

अपयशाच्या स्थिती आणि दिसणारे संदेश

रीबूटनंतर container नाहीसा होतो. प्रथम loginctl show-user ollama --property=Linger तपासा, कारण Linger=yes शिवाय वापरकर्त्याचा systemd instance boot वेळी सुरू होत नाही. lingering सुरू असल्यास, .container फाइलमध्ये [Install] section नसतो किंवा तुम्ही फाइल संपादित केल्यानंतर systemctl --user daemon-reload चालवलेले नसते.

Error: statfs /home/ollama/ollama-data: no such file or directory. Container सुरू होण्यापूर्वी bind mount source उपलब्ध असणे आवश्यक आहे. Podman तुमच्यासाठी host directories तयार करत नाही. ollama user म्हणून mkdir -p ~/ollama-data चालवा.

90 seconds नंतर सुरू होणे अयशस्वी होते. Image pull अद्याप सुरू असल्यामुळे journalctl --user -u ollama.service मध्ये Start operation timed out. Terminating. दिसते. Pull manually करा किंवा TimeoutStartSec=900 तसेच ठेवा.

Container सुरू होऊन बंद होतो. podman logs ollama आणि sudo ausearch -m avc -ts recent यांच्या आधारे समस्या SELinux label मुळे आहे का हे समजते. container_t आणि user_home_t यांचा उल्लेख करणारा AVC संदेश दिसल्यास :Z उपलब्ध नसतो.

Host कडून requests नाकारल्या जातात. Service active सह curl: (7) Failed to connect to 127.0.0.1 port 11434: Connection refused सामान्यतः container मध्ये OLLAMA_HOST loopback address वर सेट केले असल्याचे दर्शवते. ती line काढा.

Generation खूप धीमे होते किंवा container बंद केला जातो. GPU नसल्यास inference CPU वर चालते आणि मोठे model स्वभावतः धीमे असते. Logs मध्ये signal: killed दिसत असताना request च्या मध्यात container बंद होत असल्यास तो kernel चा out-of-memory killer आहे. त्यामुळे वरील chart मधून लहान tag निवडा.

पिन केलेली image अपडेट करणे

Pinning मुळे updates आपोआप होत नाहीत; त्या तुम्ही स्वतः करता. ollama.container मधील Image= संपादित करा, त्यानंतर reload आणि restart करा:

systemctl --user daemon-reload
systemctl --user restart ollama.service
podman exec ollama ollama --version

Models bind mount मध्ये असतात, त्यामुळे image बदलल्यानंतरही ते तसेच सुरक्षित राहतात. [Container] विभागातील AutoUpdate=registry ही नोंद moving tag वापरणाऱ्या लोकांसाठी आहे. Fixed version tag सोबत तिचा उपयोग होत नाही, कारण त्या tag मधील contents कधीही बदलत नाहीत. /home/ollama/ollama-data/models/manifests आणि .container file चा backup घ्या आणि blobs वगळा. ते मोठे असतात आणि नवीन box वर ollama pull ते पुन्हा fetch करते.

FAQ

माझा rootless Podman container logout केल्यानंतर का थांबतो?

वापरकर्त्याचे शेवटचे session संपल्यावर त्या वापरकर्त्याचा systemd instance आणि त्याची /run/user/<uid> directory काढून टाकली जाते. त्यामुळे सर्व rootless container देखील थांबतात. sudo loginctl enable-linger ollama चालवा आणि loginctl show-user ollama --property=Linger मध्ये Linger=yes छापले जाते याची खात्री करा. Quadlet unit तयार करण्यापूर्वी lingering enable करा, कारण त्या unit ला आवश्यक असलेली runtime directory lingering सुरू झाल्यानंतरच उपलब्ध होते.

Ollama model directory वर SELinux labels आवश्यक आहेत का?

Fedora, RHEL, Rocky आणि AlmaLinux वर host directory bind mount करत असल्यास होय. Container container_t domain मध्ये चालतो आणि home folder मधील directory ला user_home_t label असते. त्यामुळे write नाकारली जाते आणि Ollama बंद होते. Volume= line मध्ये :Z जोडा आणि त्यासाठी स्वतंत्र subdirectory वापरा, कारण relabelling recursive असते. :Z संपूर्ण home directory कडे निर्देशित केल्यास त्या वापरकर्त्याचा SSH key access बंद होतो. Podman named volumes ना योग्य labels लावतो; त्यामुळे अतिरिक्त बदल आवश्यक नाहीत.

Ollama model साठी किती disk space आवश्यक आहे?

ollama.com/library वर दिलेल्या download size पासून सुरुवात करा. तो 3.3 GB gemma3:4b साठी, ते 19 GB qwen3:30b साठी इतका असतो. त्यावर Podman image साठीची जागा जोडा. मोकळी जागा राखून ठेवा, कारण दुसरे model disk वरील पहिले model बदलत नाही. Pull करण्यापूर्वी df -h /home तपासा आणि त्यानंतर du -sh ~/ollama-data/models तपासा. RAM चेही त्याच पद्धतीने नियोजन करा: model लोड असताना त्याला साधारणपणे त्याच्या file size एवढी memory, तसेच context window साठीची memory आवश्यक असते.

VPS वर port 11434 सार्वजनिक करणे सुरक्षित आहे का?

नाही. Ollama मध्ये कोणत्याही प्रकारचे authentication नसते. त्यामुळे port पर्यंत पोहोचणारी व्यक्ती तुमचे models list किंवा delete करू शकते, disk वर नवीन models pull करू शकते आणि तुमच्या CPU तसेच bandwidth allowance वर inference चालवू शकते. इंटरनेटवरील plain HTTP मुळे प्रत्येक prompt आणि completion cleartext मध्ये पाठवले जाते. Host side ला PublishPort=127.0.0.1:11434:11434 वापरून 127.0.0.1 वर bind करा, ss -ltnp | grep 11434 वापरून ते तपासा आणि password आवश्यक असलेल्या SSH tunnel किंवा reverse proxy द्वारे त्याच्याशी connect करा.

#ollama#podman#rootless#quadlet#selinux#systemd