VPS куплен, SSH-сессия открыта. У многих здесь возникает пауза: непонятно, с чего начать и под какую задачу настраивать VPS-сервер. Разберём пять практических сценариев того, как использовать VPS: хостинг сайтов, запуск ботов, размещение API, мониторинг и автоматизация. У каждого – конкретный стек, ориентиры по ресурсам и нюансы, которые лучше знать до начала настройки, а не в процессе. Реальные требования зависят от сложности проекта, нагрузки, выбранного стека и числа одновременно работающих сервисов.

Что даёт VPS и почему его берут

VPS-сервер отличается от shared-хостинга тремя вещами. Первое – у вас есть заявленные параметры тарифа: CPU, RAM, диск и сетевой канал. На качество работы всё ещё может влиять общая инфраструктура хоста, но изоляция здесь выше, чем на shared-хостинге. Второе – root-доступ: можно установить любой софт, выбрать версию PHP, настроить nginx под конкретную задачу. Третье – VPS-сервер работает круглосуточно без вашего участия, независимо от состояния вашего компьютера или интернета. На shared-хостинге чужая нагрузка может повлиять на соседние сайты, если провайдер плохо ограничивает ресурсы аккаунтов.

От облачных функций (AWS Lambda, Yandex Cloud Functions) VPS отличается предсказуемостью: нет cold-start задержек, нет тарификации за каждый вызов функции, нет ограничений по времени выполнения. Для задач с постоянными процессами: баз данных, ботов, мониторинга – VPS часто проще и предсказуемее, чем serverless-архитектура с оплатой за вызов. При низкой или нерегулярной нагрузке serverless может оказаться дешевле.

Базовая подготовка: что сделать сразу после покупки

Настройка VPS начинается не сразу с рабочего проекта, а с базовой конфигурации. Базовая настройка снижает риск классических проблем: открытого SSH, устаревших пакетов, лишних портов и нехватки памяти при пиковых нагрузках. Пропуск таких шагов может увеличить риск потерять сервер из-за брутфорса или случайной команды от root.

•  SSH-ключи. Сгенерируйте пару через ssh-keygen, передайте публичный ключ через ssh-copy-id, отключите аутентификацию по паролю в sshd_config.

•  Пользователь без root. Создайте аккаунт с правами sudo. Работа от root в продакшене – плохая практика. Одна ошибка может стоить всей системы.

•  Firewall. Откройте в UFW SSH-порт, 80 и 443, если они нужны вашему сценарию. Если используется стандартный SSH-порт, это 22. Fail2ban добавит защиту от брутфорса на SSH.

•  Swap. Если RAM меньше 2 ГБ, добавьте swap-файл на 1–2 ГБ. Он снижает риск OOM при пиковой нагрузке, но при активном использовании может ухудшить производительность.

•  Обновления. Запустите sudo apt update && apt upgrade сразу после входа на сервер, до начала любой работы.

Сценарий 1. Хостинг сайтов и веб-проектов

Хостинг на VPS оправдан, когда shared-хостинг перестал справляться: нет нужной версии PHP или Python, не хватает памяти, несколько доменов требуют разных настроек или нестандартного ПО. На VPS больше свободы в настройке: можно выбрать версии ПО, настроить веб-сервер, подключить нужные модули и управлять несколькими проектами независимо. Именно поэтому многие переезжают сюда с первого же конфликта с техподдержкой shared-хостинга.

Стек: Nginx как веб-сервер и reverse proxy, PHP-FPM для WordPress или других CMS, MySQL или PostgreSQL как база данных. Для статических сайтов (Hugo, Astro, Next.js SSG) Nginx работает без интерпретатора, нагрузка минимальная. SSL – Let’s Encrypt через Certbot, бесплатно и с автообновлением. Один Nginx обслуживает несколько доменов через server blocks.

Порты СУБД (3306, 5432) наружу не открывайте: приложение обращается к базе внутри сервера. Для сайта с умеренным трафиком часто хватает 1 vCPU и 1–2 ГБ RAM; для тяжёлых CMS с кешированием, большим числом плагинов или высокой посещаемостью лучше закладывать 2 vCPU и 2–4 ГБ. Добавьте Redis для кеша сессий: это может снизить нагрузку на базу данных и улучшить отклик WordPress при росте трафика.

Сценарий 2. Запуск Telegram- и Discord-ботов

Боту часто нужно работать круглосуточно и хранить состояние: настройки пользователей, историю диалогов, очереди задач. Локальная машина для этого не подходит, а облачные функции удобны в основном для коротких команд без постоянного процесса. VPS решает обе задачи: бот постоянно запущен, а база данных может работать рядом на том же сервере.

Стек для Telegram: Python + aiogram, управление процессом через systemd, хранение состояния в SQLite или PostgreSQL. SQLite подходит для небольших ботов с умеренной нагрузкой, но при высокой конкуренции запросов или запуске нескольких экземпляров приложения лучше сразу выбирать PostgreSQL. Для Discord – Node.js + discord.js, для управления процессом удобен PM2. Redis подойдёт для быстрого хранения временных данных и очередей.

Для большинства продакшен-сценариев с Telegram-ботами удобен webhook-режим: сервер сам получает обновления, не опрашивая API Telegram. Для webhook нужен домен с HTTPS. Polling тоже остаётся корректным вариантом для небольших проектов: он проще в запуске и не требует домена с HTTPS. Простой бот без базы данных умещается на 1 vCPU и 1 ГБ RAM. Бот со сложными очередями, вызовами внешних API и ML-моделями потребует минимум 2 ГБ RAM. Через systemd настраивается автозапуск: после перезагрузки сервера бот поднимется сам.

Сценарий 3. Размещение API и бэкендов

VPS-сервер даёт API постоянный адрес, свою базу данных и полный контроль над окружением, без vendor lock-in и без ограничений по времени выполнения запросов. Это важно для бэкендов с длительными операциями: обработкой файлов, парсингом, генерацией отчётов.

Стек: FastAPI (Python) или Express.js (Node.js) для REST, Docker для изоляции сервисов, Nginx или Traefik как reverse proxy. Приложение слушает на localhost, наружу открыты только 80 и 443. GraphQL – Strawberry (Python) или Apollo Server (Node.js). Для автодеплоя – GitHub Actions: пуш в main запускает пересборку и перезапуск контейнера.

Порты базы данных держите внутри Docker-сети, не открывайте наружу: бэкенд обращается к базе по имени сервиса внутри сети. Для API с базой данных начинайте с 2 vCPU и 2–4 ГБ RAM. При росте нагрузки Docker и reverse proxy позволяют масштабировать сервисы без переписывания архитектуры. Traefik автоматически получает и обновляет SSL-сертификаты через Let’s Encrypt при настроенном ACME, поэтому отдельная настройка Certbot не нужна.

Сценарий 4. Мониторинг и сбор метрик

Сервер мониторинга должен работать независимо от мониторируемой инфраструктуры. Если основной сервер упал, система мониторинга должна увидеть это первой и отправить алерт, а не упасть вместе с ним. Отдельный небольшой VPS для мониторинга решает эту задачу.

Uptime Kuma – удобный инструмент с веб-интерфейсом: отслеживает HTTP-статусы, время ответа, порты TCP, отправляет алерты в Telegram, Slack и другие каналы. Разворачивается через Docker за несколько минут и обычно помещается в небольшой VPS. Для лёгкого мониторинга часто достаточно 512 МБ RAM, но потребление зависит от числа проверок и их типа.

Prometheus + Grafana – полный стек для сбора метрик, построения дашбордов и настройки алертов. Prometheus собирает данные с exporters, Grafana строит графики. Оба сервиса вместе могут потреблять примерно 600–1000 МБ RAM в покое, но фактическое потребление зависит от retention, числа targets и объёма метрик. Под этот сценарий обычно стоит закладывать не меньше 2 ГБ RAM. Node Exporter собирает системные метрики хоста – CPU, RAM, диск, сеть; добавьте его на каждый наблюдаемый сервер. Алерты в Telegram настраиваются через Alertmanager за несколько минут.

Сценарий 5. Автоматизация и рабочие процессы

Сервер не выключается. Это главное преимущество VPS для автоматизации: cron-задачи запускаются по расписанию в любое время суток, скрипты работают столько, сколько нужно, без ограничений по времени выполнения и без зависимости от того, включён ли ваш компьютер.

n8n – self-hosted инструмент для визуальной автоматизации, аналог Zapier на вашем сервере. Разворачивается через Docker, а потребление памяти может начинаться примерно от 500 МБ RAM и расти с числом workflow, интеграций и выбранной БД. Данные о задачах хранятся в БД, поэтому volume для персистентности обязателен. Настроенный VPS с n8n заменяет подписку на облачные сервисы автоматизации и не передаёт данные третьим сторонам.

Для простых задач достаточно cron: бэкап файлов, отправка отчётов, очистка временных директорий, синхронизация данных между сервисами.

Как выбрать свой сценарий и не перегрузить сервер

Примерные ориентиры по ресурсам под основные задачи:

•  Сайт или бот без тяжёлых фоновых задач: 1 vCPU, 1–2 ГБ RAM

•  API с базой данных: 2 vCPU, 2–4 ГБ RAM

•  Prometheus + Grafana: 2 vCPU, 2–4 ГБ RAM

•  n8n плюс несколько сценариев одновременно: 2–4 vCPU, 4–8 ГБ RAM

Несколько сценариев на одном VPS совместить возможно, но требования зависят от сложности проекта, выбранного стека, объёма трафика и числа одновременно работающих сервисов. Для простого сайта, небольшого бота и лёгкого мониторинга 2 ГБ RAM могут быть достаточны, если нет тяжёлых фоновых задач. Docker упрощает совмещение: каждый сервис в своём контейнере, порты не конфликтуют, ресурсы лимитируются. Постоянная загрузка CPU или RAM выше 80% может стать сигналом для апгрейда. Начните с минимального тарифа и расширяйте по мере роста – большинство провайдеров позволяют сделать это без пересоздания сервера.

Чек-лист: что настроить на VPS под любой сценарий

1.  SSH-ключи настроены, аутентификация по паролю отключена

2. Создан sudo-пользователь, работа от root прекращена

3. Система обновлена: sudo apt update && apt upgrade

4. UFW включён: открыты только нужные входящие порты, например SSH-порт, 80 и 443 для веб-сценариев

5. Swap настроен при RAM < 2 ГБ

6. Автоматические снапшоты или бэкапы настроены

7.  Домен привязан, HTTPS работает через Let’s Encrypt

8.  Базовый мониторинг: uptime и диск под контролем

VPS это не готовый продукт, а платформа для разных задач: сайта, бота, API, мониторинга или автоматизации. Начните с одного сценария, не пытайтесь запускать всё сразу. Сначала закройте базовую настройку из чек-листа: SSH-ключи, firewall, обновления, бэкапы и мониторинг. После этого разверните минимальную рабочую версию сервиса и расширяйте конфигурацию по мере роста нагрузки.

---

## Как я считал

Два источника.

**hh.ru.** Только совпадения в названиях вакансий. Без поиска по описанию — там слишком много шума. Пятнадцать запросов: Python, Java, Go, PHP, Node.js, C# — плюс их комбинации с fullstack и React. Фильтр: вся РФ, зарплата любая.

**Хабр Карьера.** 43 716 анкет, июль 2026. Медианы, а не средние — чтобы пара зарплат из Яндекса не перекосила картину.

Даты: 14–20 июля 2026. Всё руками. Без скриптов.

Что нельзя гарантировать:

Поиск по заголовкам режет абсолютные цифры. Вакансия «Senior разработчик» без языка в названии — мимо выборки. Но пропорции держиЎ смещение одно и то для всех языков.

Это срез недели. Не годовой тренд.

Закрытый рынок (внутрянка, рекомендации) не виден. Совсем.

Регионы: Москва и Ульяновск — разные галактики. Мои цифры — среднее по стране, а не по столице.

И всё же. Для карьерного решения точности достаточно.

---

## Общий рынок: Python — 519. Но это ловушка

Беру все бэкенд-вакансии. Без фильтрации. Грубая масса:

> 📊 **[ВСТАВИТЬ КАРТИНКУ: horiz_bar.png]**

- Python — 519

- Java — 468

- C#/.NET — 227

- PHP — 207

- Go — 141

- Node.js — 62

- TypeScript (бэкенд) — 53

- Ruby — 15

Python вдвое опережает C#. Картинка ясная?

Нет.

Я открыл эти 519 вакансий. Добрая половина — Data Science. Нейросети. ML. Автоматизация. Python-разработчик в банке может не писать API вообще — он обучает скоринговые модели. К fullstack это имеет слабое отношение.

Сырые цифры врут. Красиво врут — но врут. Нужна другая выборка.

Теперь Node.js и TypeScript. Если считать их одним (TypeScript-бэкенд — NestJS или Next.js, технически Node.js), вместе — 115. Третье место, сразу за Python и Java. По-моему, так честнее. Но в таблицах ниже я их разделяю — для прозрачности.

Go — 141. Много для 15-летнего.

PHP — 207. Язык, который «умер» в 2012. В 2015. В 2018. В 2020. 207 вакансий. Никак не добьют.

Ruby — 15.

---

## Fullstack-срез: PHP на первом месте. Я перепроверил трижды

Дальше — фильтрую. Только вакансии, где в заголовке или первом абзаце чётко: «фронтенд + бэкенд». Пришлось вручную просмотреть около 200 штук. Некоторые заголовки врут: написано «Fullstack Developer», внутри — чистый бэкенд.

> 📊 **[ВСТАВИТЬ КАРТИНКУ: fullstack_bar.png]**

- PHP — 30

- Python — 29

- Java — 28

- C#/.NET — 21

- Node.js — 15

- TypeScript — 10

- Go — 2

- Ruby — 1

PHP.

На первом месте.

Я не поверил. Пересчитал. Ещё раз. Цифра честная.

Только вот интерпретация. PHP вырвался не потому, что это лучший язык для веба — а потому что Laravel-экосистема исторически fullstack. Фреймворк даёт бэкенд и Blade-шаблоны из коробки. В вакансиях на Laravel ищут одного человека: база, API, фронт — всё он. Это артефакт экосистемы. Не сигнал «беги учить PHP».

Node.js + TypeScript — 25. Второе место. Я ждал меньше. Думал, fullstack занят PHP и Java, а Node.js где-то в нише. Ошибся.

Go — две вакансии на всю страну.

Две.

Не случайность. Go проектировали для микросервисов, не для fullstack. Искать fullstack на Go — как спорткар с кузовом универсал. Можно, но зачем.

### Несколько цифр без прикрас

- Fullstack-вакансий в выборке: 330

- Удалёнка: 190 (58%)

- Senior: 61, Middle: 24

- hh.индекс: 8,3 — конкуренция

- Динамика: вакансий +8%, резюме −2%

61 senior, 24 middle. В 2,5 раза.

Fullstack — не входная точка в IT. Сначала стань кем-то одним. Потом расширяйся. Рынок ждёт опытных, а middle-позиции подбирает по остаточному принципу.

---

## React + бэкенд: график, ради которого я это затеял

Главный вопрос. Какие бэкенды реально ищут в паре с React? Не «упомянут где-то в глубине требований» — прямо в заголовке или первом абзаце:

> 📊 **[ВСТАВИТЬ КАРТИНКУ: react_combos.png]**

- React + Node.js — 16

- React + PHP — 9

- React + Python — 8

- React + Java — 6

- React + .NET — 5

- React + Go — 1

16 против 9. Node.js отрывается почти вдвое.

И вот что интересно. На общем рынке Node.js — скромный середняк: 62 вакансии. В fullstack-нише — третье-четвёртое место. А в связке с React — уверенное первое.

Не самый массовый бэкенд вообще. Но для React-фронтендера — самый частый выбор нанимателя.

Почему? Четыре причины, которые, по-моему, не случаются сами собой:

**Один язык.** TypeScript на клиенте и на сервере. Типы кочуют туда-сюда без переписывания. DTO описал один раз — работает везде.

**Next.js размывает границу.** API routes, Server Components, Server Actions. Разработчик на Next.js пишет бэкенд, часто не замечая.

**NestJS — когда Next.js маловато.** Модульная архитектура, DI, guards, interceptors. Enterprise-уровень на знакомом TypeScript.

**Общий тулинг.** Zod для валидации, date-fns для дат, shared-библиотеки в монорепе. Никакого дублирования.

React + PHP (9 штук) — обычно Laravel на бэке, React как админка или SPA. Работает. Особенно в e-commerce.

React + Go (1 штука).

Одна.

Кто-нибудь вообще видел такую вакансию вживую? Отпишитесь, мне правда интересно, что за проект.

---

## Деньги: где самый толстый скачок

Хабр Карьера, 43 716 анкет. Медианы.

> 📊 **[ВСТАВИТЬ КАРТИНКУ: salaries.png]**

- Intern — 66 000 ₽

- Junior — 95 000 ₽

- Middle — 177 000 ₽

- Senior — 303 000 ₽

- Lead — 378 000 ₽

Ступеньки: Junior → Middle — плюс 82 тысячи. Middle → Senior — плюс 126 тысяч. Senior → Lead — плюс 75 тысяч.

Самый крутой подъём — между middle и senior. Рынок платит за глубину. Fullstack-middle, который «всё понемногу», стоит сильно дешевле fullstack-senior, который глубоко знает оба направления.

Что за кадром:

Разброс внутри грейдов — пропасть. Senior fullstack в региональной веб-студии и senior fullstack в финтехе живут в разных финансовых измерениях.

Хабр Карьера смещена вверх. Те, кто получает мало, реже заполняют анкеты.

Зарплаты по языкам — за регистрацией. Я не знаю, получает ли PHP-senior столько же, сколько Node.js-senior. Подозреваю, что нет. Доказательств у меня нет.

---

## Удалёнка: 190 из 330

190 fullstack-вакансий из 330 — удалённые.

Я в Ульяновске. Ближайшие офисы крупных IT — Казань, Самара. С удалёнкой это не проблема: работаешь на Москву или Питер из квартиры с видом на Волгу.

Деталь: большинство удалённых fullstack-позиций — аутсорсинг и стартапы. Enterprise осторожничает. Банки. Телеком. Им всё ещё нужен офис. Хотите Java в банке — готовьтесь к гибриду как минимум.

---

## Что я выбрал

Node.js + NestJS + TypeScript.

Не «потому что модно». Пять вещей, которые перевесили:

**Язык один.** Пишу на TypeScript больше пяти лет. Декоратор `@controller()` в NestJS — продолжение того, что знаю. Не прыжок в другую вселенную.

**16 против 1.** React + Node.js — 16 вакансий, React + Go — одна. Работодатель, которому нужен fullstack на React, ждёт Node.js. Мне не надо его переубеждать.

**Потолок далеко.** Простой CRUD на NestJS — за вечер. Дальше — CQRS, event-driven, микросервисы на Kafka/NATS. Есть куда расти.

**Next.js как трамплин.** Server Actions и API Routes — это бэкенд, просто в рамках одного фреймворка. Переход к NestJS — структурирование тех же концепций.

**Одна кодовая база.** Типы, валидация, утилиты живут в одном месте. Без дублирования.

Что через год-два? Не знаю. Может, вторым языком возьму Python + FastAPI — мост в AI/ML-проекты. Может, останусь в Node.js и пойду в ширину: базы данных, инфраструктура, девопс.

Посмотрим.

---

## Если примерять к себе

Ты React/TypeScript-фронтендер? **Node.js, NestJS.** Язык знаешь, рынок подтверждает, вход плавный.

Ты в Data Science / ML? **Python, FastAPI.** Строить веб вокруг ML-моделей — редкая комбинация. Только учти: вакансий меньше, чем в чистом вебе.

Ты в enterprise или планируешь? **Java / C#.** Стабильно. Дорого. Порог входа высокий, экосистема тяжёлая.

Любишь highload и инфраструктуру? **Go.** Fullstack-позиций почти нет. Но как чистый бэкенд — мощно.

Нужна работа прямо сейчас? **PHP, Laravel.** 30 fullstack-вакансий — больше всех. Только готовься к культурной адаптации после TypeScript.

---

Четыре вещи, которые остались после подсчётов.

Node.js — не самый большой рынок. Но для React-фронтендера — точка входа с наименьшим сопротивлением. 16 против 1. Не погрешность.

Fullstack — не старт. 61 senior-вакансия, 24 middle. Сначала глубина. Потом ширина.

Один язык на клиенте и сервере — не «удобно». Это скорость. Меньше ошибок, общий тулинг, никаких «забыл обновить типы после смены API».

Цифры — не догма. Срез июля 2026. Через полгода пересчитаю — и не поручусь, что картина не изменится.

Пишите в комментариях, какой бэкенд выбрали вы. И главное — почему. Реальный опыт интереснее любых цифр.

А если кто-то видел fullstack на Go вживую — маякните. Мне правда интересно.

---

*Данные: hh.ru и Хабр Карьера, 14–20 июля 2026, РФ. Поиск по заголовкам — абсолютные цифры занижены, пропорции репрезентативны. Детальные зарплаты по языкам — за регистрацией, не включены. Региональные перекосы возможны.*

В панели сразу можно смотреть забитость окна, потраченные $, время генерации, и тд

- Режим 1 - Обычный мод, где выбрать можно будет 1 модель, и она будет отвечать

- Режим 2 - Коллективный, где можно выбрать 2 модели, которые думают, и судья выберет лучший ответ, и дополнит его если надо (Думаю улучшить этот мод, чтобы не 3 модели было, а по + можно было добавить сколько угодно)

- Так же у выбранного проекта есть кнопка перехода в режим IDE, где я сделал можно сказать vs code, чтобы сразу можно было перейти в чать какую-то отрезка, и сразу просмотреть или отредактировать.

3) vpn - просто пока что, потому что недавно сделал, где есть статус подключения, сервера, кнопка подключения (я на своем сервере развернул 3x-ui, и подключаюсь к своему личному серверу, но я столкнулся с таким приколом, что впн порой плохо работает, и я пока не понимаю, как мне улучшить его, чтобы он был качественным, и быстрым)

4) запрет - альтернатива впн, порой когда он не требуется, то просто включить запрет. У я хочу сделать, чтобы по кнопке rotate, у меня шел запрос на github автора, и если там есть новые изменения, то они будут скачиваться ко мне на бек (типа как обновление), чтобы я быстро получал актуальную сборку по 1 клику, и запускал.

P.S

Я знаю, что автора пока что забанили на время, как он говорит, поэтому я просто пока узнаю можно ли так сделать, если это не мой личный репозиторий.

5) Хранилище - когда я доделаю прогу, и отправлю бек на сервак, то он еще будет как хранилище, где я смогу создать папку к примеру для видео, png или лого для сайтов и тд.

И идея заключается в том, если я понимаю, что мне надо будет в другое место пойти не у своего рабочего пк, а с ноутом, то я сомгу зайти в совою прогу, и с сервера забрать что-то нужное.

Так же идея расширения функционала, это после завершения создания, сделать урезанную версию, и скинуть другу, чтобы он то же использовал хранилище, где ключевой фишкой этой вкладки будет общая папка, и добавить человека, где я смогу что-то закидывать (к примеру моды для майна), и он зайдет в эту папку, и скачает от туда их.

6) Заметки - думаю тут не особо есть, что говорить, просто я думаю расширить это для более значимого что-то, где будет отслеживание прогрессов, анализ ии, и цели.

7) Заявки - т.к я порой беру заказы в тг каналов, то я хочу автоматизировать процесс, где бот заходит на мой акк, и делает рассылку с моего профиля, предоставления моих услуг, и когда человек будет мне писать (подумаю как сделать фильтрацию, чтобы люди с каналов в прогу попадали только)

И в заявках будут появляться карточки, от человека, откуда он пишет, тема, само сообщение, ник, и я смогу либо после разговора с ним принять заявку или отменить.

P.S

Так же я еще делаю свой сайт, который потом думаю продвигать так же о предоставлении своих услуг, и думать как улучшить SEO, и люди смогут так же оставлять заявку, и эти заявки будут так же мне в прогу приходить.

8) Удаление фона - т.к я 90% фронт, и я часто редактирую картинки, удалить фон и тд, то у меня есть быстрый редактор, куда я закинул фото, и получил ее без фона в png

8) Скачать видео - тоже часто пользуюсь для како-то фона на сайте, и часто беру с pinterest, то я просто копирую ссылку, вставляю, и получаю его скаченным (потому что видео нельзя скачать от туда)

9) Виджеты - сделал все виджеты интерактивными, чтобы быстро взаимодействовать, и для быстрой статистики.

- Дата

- Впн (вкл/выкл/перезагрузка)

- Сколько осталось места в хранилище

- Погода

- Последний проект в аи чате (перейти)

- Время

- Своя картинка

- Перетащить картинку для удаления фона

- Вставить ссылку для скачивания видео

- Таймер (запускаю его, чтобы смотреть сколько я работал) / Секундомер (если надо сделать отсчет)

- Активность за неделю (блок как в гитхабе)

- Работа пк (выключить, перезагрузка, спящий режим) по нажатию на любую из этих кнопок идет таймер 3 > 2 > 1, чтобы при повторном нажатии если что отменить.

P.S

Виджеты можно включать/выключать, перемещать по всему экрану, и так же отслеживаются мониторы, чтобы они на каком-то определенном мониторе показывались

10) Сервера - еще не сделал, но я хочу сделать как в termius, чтобы был список своих серверов, подключится к ним, и файлы перекидывать на сервак

11) Настройки - бональщина пока что по типу автозапуска, тема, страница по умолчанию и тд. (не знаю, что еще пока добавить нужного)

---------------------------------------------------------------------------------------------------

А теперь почему я вообще создал этот пост.

Я просто хочу услышать какие-то еще идеи, которые на самом деле нужные, но они пока мне в голову не приходят.

Я еще думал, что чтобы у меня в панели мой гит был, чтобы я если что мог сразу перейти в свой репозиторий и тд, но пока не углублялся этим вопросом.

P.S

Так же думал потом сделать может быть свое личное приложение, где будет какой-то функционал, где будет мой впн, где могу делать подключение, дистанционное выкл пк (иногда, когда прилег, а уже вставать не охота, то с телефона просто выключил пк, и все)

У меня айфон, и поэтому тут еще проблема, как сделать приложение для себя, и скачать его, я знаю, по типу альстор, но каждые 7 дней ради этого мне надоест переустанавливать сертификат.

Поэтому идея, которая мне пришла это сделать так же как банки веб версию, где закрепить ее домой, и будет открываться типа приложение, но я пока не знаю, как точно это работает. Это просто обычный адаптив? когда мобилка, то просто приложение показывается?

---------------------------------------------------------------------------------------------------

Подкиньте идей, что можно полезного еще сделать, или улучшить из того, что есть, чтобы оно правда стало полезным.

P.S

Стек:

Фронт - Electron + React TypeScript + Scss (думаю потом сделать из electron на tauri, чтобы нагружало меньше ram, но пока что нет)

Бек - Python + FastAPI

Бд - SQLite (может быть если будет масштабный проект, и если я выпущу урезанную версию для всех, то может переделаю на postgresql)

[myproject.local]

web_engine = Nginx # или Apache

php_engine = PHP-8.2

public_dir = {base_dir}\public

В 5 версии было все более нативной , настраивалось через графическое дерево в меню open server , новый же подход позволяет задать более гибкие настройки.

3)Далее включаем модули , глобальный и для проекта отдельно.

Глобально через меню open server модули =>http=> выбираем нужный веб движок apache или nginx

После настройки глобальных модулей , мы можем настроить , веб сервер и версию php , локально для проекта

Так же локальная настройка , доступна через тот самый файл project.ini , про который я писал выше .В прошлых же версиях все было более проще , через трей интерфейса.

4) Что касается файла project.ini , и настройки корневой папка .Если файл лежит именно в корне проекта , оставляем настройку

[myproject.local]

public_dir = {base_dir}

если же присутствуют подпапки,как в laravel к примеру :

home/

└── myproject.local/

├── app/

├── config/

├── public/ ← вот она, папка с точкой входа

│ ├── index.php

│ └── style.css

├── storage/

└── vendor/

То добавляем через / название папки где находится наша точка входа в приложение

[myproject.local]

public_dir = {base_dir}/public

Думаю тут понятно что этой настройкой мы указываем откуда серверу отдавать файлы , где находится наша точка входа

Что будет, если не указать public_dir?

Без public_dir в project.ini домен появится, но сервер не будет знать, откуда отдавать файлы, и вы увидите ошибку 404 или пустую страницу.

5)Как теперь работают домены (Прощай, файл hosts!)

В 5-й версии мы были обязаны вручную править системный файл C:\Windows\System32\drivers\etc\hosts, прописывая туда строки вида 127.0.0.1 myproject.local.

В Open Server 6 всё работает иначе:

В программу встроен собственный DNS-сервер.

При запуске OSP 6 автоматически перехватывает DNS-запросы на вашем компьютере.

Как только вы прописали имя проекта в скобках [myproject.local] внутри project.ini, программа сама связывает этот домен с нужным внутренним IP-адресом.

Вам больше не нужно трогать файл hosts — Windows мгновенно увидит ваш сайт по его DNS-имени. Если вам всё же нужен доступ по IP, проект по умолчанию доступен на локальном адресе http://127.0.0.1 (или с указанием конкретного порта, если вы изменили его в глобальных конфигах)

6)Важное изменение при подключении к БД (MySQL)

Раньше в конфигурационных файлах ваших сайтов (например, в .env файле Laravel или wp-config.phpв WordPress) в строке подключения к базе данных (DB_HOST) мы всегда писали localhost или 127.0.0.1.

В OSP 6 из-за изолированной архитектуры модулей localhost больше не работает!

Теперь для подключения к MySQL нужно использовать:

DNS-имя модуля: Например, MySQL-8.2 (указывайте ровно то имя, которое запущено у вас в системе).

Или конкретный IP-адрес: По умолчанию OSP 6 выделяет модулям баз данных адреса в локальной подсети. Чаще всего это 127.0.0.1, но с уникальным портом, либо выделенный IP из диапазона 127.x.x.x (смотрите точный IP/порт в консоли OSP при старте модуля).

Пример настройки файла .env ,в проекте

DB_CONNECTION=mysql

DB_HOST=MySQL-8.2 # Вместо localhost пишем имя модуля DNS

DB_PORT=3306

DB_DATABASE=my_db

DB_USERNAME=root

DB_PASSWORD=

Вот и все основные нюансы для запуска проекта в open server v6.

А если вы не знаете какой веб-сервер выбрать apache или nginx .Об этом я тоже расскажу в след. посте.

Если вам интересна тема веб-разработки, я также публикую разборы других кейсов в своем Telegram-канале и на Максе. Буду рад единомышленникам.