Как я собрал личную Codex-станцию: новый MacBook, Mac mini и два iPhone

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

У меня был MacBook Air M4 с 16 ГБ памяти. Хорошая, лёгкая, удобная машина. Но в какой-то момент стало понятно: для моего текущего режима этого уже мало. Постоянно открыты браузеры, Codex, несколько проектов, локальные dev tools, чаты, Notion, Linear, GitHub, иногда Docker, иногда локальные серверы, иногда аудиты и длинные рабочие сессии. Всё это не похоже на один аккуратный сценарий “открыл ноутбук, написал текст, закрыл ноутбук”. Это уже постоянный рабочий контур.

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

• MacBook Air M5 с 32 ГБ памяти — как мобильная рабочая машина;
• Mac mini M4 Pro с 48 ГБ памяти — как постоянный домашний devbox и Codex-host;
• два iPhone — как мобильные точки управления;
• домашняя сеть, NAS, Tailscale/Headscale, VPN и GitHub — как инфраструктурный слой вокруг этого.

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

И в итоге это стало не историей “купил новый Mac”. Это стало историей “собрал личную Codex-станцию”.

Почему просто нового MacBook было мало

Самый простой путь был бы такой: купить новый MacBook, перенести данные, продолжить жить как раньше.

Но проблема была не только в объёме памяти. Проблема была в том, что один ноутбук стал выполнять слишком много ролей одновременно.

Он был экраном, клавиатурой, devbox, местом хранения проектов, точкой запуска Codex, клиентом для GitHub, машиной для браузера, локальных серверов, SSH, VPN и кучей всего ещё. Когда вся работа держится на одном ноутбуке, он становится не просто компьютером, а узким местом.

Новый MacBook Air M5 с 32 ГБ памяти решает часть проблемы: больше воздуха для повседневной работы, браузера, Codex, проектов и созвонов. Но мне хотелось сразу сделать схему устойчивее. Поэтому рядом появился Mac mini M4 Pro с 48 ГБ памяти.

И вот тут всё стало интереснее.

Новая схема: MacBook как пульт, Mac mini как база

Я стал думать о компьютерах не как о двух отдельных устройствах, а как о ролях.

MacBook — это мобильный фронтенд. На нём удобно писать, читать, смотреть интерфейсы, работать из разных мест, управлять задачами, общаться с Codex и быстро включаться в проект.

Mac mini — это постоянный хост. Он стоит дома, рядом с роутером и хранилищем, всегда включён, держит проекты, dev tools, Docker/OrbStack, SSH, Screen Sharing, Tailscale и Codex. Он не должен быть красивым ноутбуком. Он должен быть спокойной, мощной, постоянной машиной.

В такой схеме MacBook больше не обязан тащить всё на себе. Он становится удобным рабочим интерфейсом. А Mac mini берёт на себя тяжёлые, долгие и постоянные задачи.

Это очень меняет ощущение от работы. Не “у меня есть ноутбук помощнее”, а “у меня есть маленькая персональная инфраструктура”.

Сначала нужно было не потерять старую жизнь

Перед тем как что-то переносить, я вместе со Стёпой начал с инвентаризации.

Это скучно звучит, но это была самая важная часть. Нужно было понять:

• какие проекты лежат в ~/Code;
• какие репозитории чистые, dirty, ahead или без remote;
• что восстановится через GitHub;
• что нужно сохранить bundle/patch;
• какие доступы завязаны на Keychain;
• где живёт Codex-конфигурация;
• что относится к NAS, VPN, SSH и локальным dev tools;
• какие старые папки нельзя случайно принять за актуальные.

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

Поэтому первый принцип был простой: сначала понять, что есть, потом переносить.

Переезд на новый MacBook

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

В итоге переезд прошёл через Migration Assistant. Это оказалось очень рабочим способом: соединяешь два Mac, переносишь пользователя, приложения и большую часть рабочего окружения, потом проверяешь, что всё действительно живое.

Но сама миграция — это только половина дела. После неё началась нормальная проверка:

• работает ли GitHub CLI;
• работает ли SSH;
• открываются ли проекты в ~/Code;
• запускается ли Codex;
• доступны ли Linear, Cloudflare и другие рабочие API;
• сохранились ли важные локальные файлы;
• видна ли сеть;
• есть ли доступ к NAS;
• не потерялись ли рабочие репозитории.

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

Mac mini: сначала мышка, потом архитектура

Mac mini приехал отдельно, и с ним всё началось очень по-человечески: у меня не было клавиатуры и мышки.

Сначала пришлось решить вообще базовый вопрос: как его включить и пройти первый setup. Я купил Logitech-мышь с приёмником и клавиатуру, подключил через переходник, выбрал тип клавиатуры, прошёл стартовые настройки. В этот момент вся грандиозная идея “always-on devbox host” упиралась в очень земное: работает ли мышка.

Потом началась настоящая настройка.

Mac mini получил:

• имя codex-mini;
• отдельного пользователя для разработки;
• Remote Login через SSH;
• Screen Sharing;
• Tailscale/Headscale;
• Happ как дополнительный VPN-контур;
• Codex Desktop и Codex CLI;
• GitHub auth;
• Homebrew, Node, pnpm, uv, cloudflared, jq, rg;
• Docker/OrbStack;
• набор активных проектов.

Я отдельно проверял, что Mac mini может пережить перезагрузку, вернуться в сеть, снова стать доступным по SSH и Screen Sharing, видеть NAS/Copyriot и быть готовым к работе без монитора.

В какой-то момент он перестал быть “новым Mac на кухне” и стал настоящим headless-хостом: включил, поставил рядом с роутером, отключил экран, работаешь удалённо.

Сеть: где всё становится интересным

Отдельная история — сеть.

На бумаге всё просто: есть домашняя сеть, есть Tailscale, есть Headscale, есть VPN, есть NAS. На практике всё чуть веселее. Разные VPN могут конфликтовать. Exit node может менять маршрут интернета. LAN и tailnet — это разные пути. А если хочется управлять всем удалённо, нельзя просто открыть наружу случайный порт и сказать “готово”.

В итоге я пришёл к более взрослой модели:

• дома основной быстрый путь — LAN;
• для внутренней сети между устройствами — Tailscale/Headscale;
• для внешнего интернета и обходных маршрутов — Happ/VLESS, где это нужно;
• Mac mini и NAS проверяются и по LAN, и по tailnet;
• внешний доступ делается через безопасные слои, а не через raw port forwarding.

Это даёт важное чувство: если один маршрут капризничает, я понимаю, где fallback. Не магия, а карта.

Codex на Mac mini: зачем это всё вообще

Главный смысл Mac mini — не просто “ещё один мощный Mac”. Главный смысл в постоянстве.

MacBook я открываю, закрываю, ношу, заряжаю, беру с собой. Mac mini стоит и работает. Он может держать проекты, dev servers, Docker, аудиты, длинные проверки, фоновую подготовку и локальные инструменты.

Теперь можно думать так:

• лёгкую и мобильную работу я делаю на MacBook;
• тяжёлую или долгую задачу можно запускать на Mac mini;
• локальный dev server может жить на Mac mini, а смотреть я его могу с MacBook;
• Codex может работать с проектом на том host, где это удобнее;
• инфраструктурные проверки можно выполнять рядом с NAS и домашней сетью.

Конкретные сценарии, которые теперь становятся нормальными:

• запустить аудит инфраструктурного репозитория на Mac mini;
• держать preview-сервер сайта на Mac mini и смотреть с MacBook;
• проверять проекты рядом с NAS, не гоняя данные через ноутбук;
• запускать Docker/OrbStack workloads на постоянной машине;
• делать регулярные repo-аудиты и smoke-checks;
• держать активные проекты готовыми к запуску;
• подключаться к Mac mini через Codex, SSH или Screen Sharing в зависимости от задачи.

Это уже похоже на маленький персональный cloud, только дома и под моим контролем.

Два iPhone как пульты управления

Самая неожиданно приятная часть — управление с iPhone.

Сейчас у меня подключены два iPhone, и оба могут использоваться как мобильные пульты для этой схемы. Основной iPhone — обычная повседневная точка управления. А второй — старенький iPhone SE 2, который тоже без проблем подключился и оказался вполне рабочим участником системы.

Это звучит как игрушка, пока не начинаешь представлять реальные сценарии:

• с телефона проверить, что Mac mini жив и доступен;
• открыть Codex и посмотреть статус задачи;
• быстро переключиться между MacBook и Mac mini;
• запустить или продолжить рабочий чат, не садясь за стол;
• держать старый iPhone SE как отдельный маленький экран управления;
• использовать iPhone как аварийный доступ, если ноутбук не под рукой.

Мне особенно нравится, что iPhone SE в этой схеме перестаёт быть “старым телефоном в ящике”. Он становится рабочим терминалом.

Что оказалось сложнее, чем казалось

Самое сложное было не установить программы.

Самое сложное — правильно разложить роли и границы:

• что должно жить на MacBook;
• что должно жить на Mac mini;
• что восстанавливается через GitHub;
• что нельзя тащить руками;
• где Keychain помогает, а где мешает;
• какие секреты можно использовать на devbox;
• какие доступы должны оставаться только на сервере;
• как не превратить настройку в бесконечный ритуал.

Например, на Mac mini быстро проявилась тема секретов. Keychain удобен для одного Mac и GUI-приложений, но плохо подходит как единый слой для MacBook, Mac mini и будущих VPS. Поэтому следующим отдельным проектом стал стандарт SOPS + age + mise для переносимых devbox-секретов.

Это уже не часть настройки Mac mini. Это отдельная архитектурная задача. И это нормальный признак взросления системы: когда появляется вторая машина, старые привычки “хранить всё локально где-то тут” перестают работать.

Что я получил

Теперь у меня есть новый рабочий контур:

• MacBook Air M5 с 32 ГБ памяти как мобильная рабочая машина;
• Mac mini M4 Pro с 48 ГБ памяти как always-on Codex/devbox host;
• доступ через SSH, Screen Sharing и Codex;
• сеть через LAN, Tailscale/Headscale и VPN-контуры;
• Docker/OrbStack для проектов, которым это нужно;
• активные репозитории на Mac mini;
• возможность смотреть dev servers с MacBook и iPhone;
• два iPhone как дополнительные точки управления;
• отдельный следующий трек по нормальной архитектуре секретов.

Главный итог: моя работа стала меньше зависеть от одного ноутбука.

Раньше MacBook был всем сразу: экраном, клавиатурой, сервером, местом запусков, точкой доступа к проектам, рабочим контекстом и единственным живым контуром.

Теперь роли разделены. MacBook — мой удобный интерфейс. Mac mini — постоянная вычислительная и агентная база. iPhone — быстрый мобильный пульт. NAS — хранилище. GitHub — технический источник правды. Codex — слой, который связывает это в рабочий процесс.

Что это открывает дальше

Самые интересные возможности ещё впереди.

Можно делать регулярные аудиты активных GitHub-проектов: Mac mini периодически смотрит состояние репозиториев, dirty branches, устаревшие зависимости, незакрытые TODO и готовит короткие отчёты.

Можно держать локальные preview-сервера на Mac mini и смотреть их с MacBook или iPhone. Это удобно для сайтов, внутренних инструментов, прототипов и клиентских демо.

Можно запускать тяжёлые задачи на Mac mini, а MacBook оставить лёгким и мобильным. Не надо держать ноутбук открытым всю ночь, если долгий процесс может жить на постоянной машине.

Можно постепенно выстроить нормальную систему секретов, где MacBook, Mac mini и VPS получают только те доступы, которые им действительно нужны.

Можно экспериментировать с Codex handoff: начать задачу на ноутбуке, продолжить на Mac mini, потом вернуться обратно и управлять этим с iPhone.

И можно наконец относиться к локальной инфраструктуре не как к хаосу “где-то что-то установлено”, а как к маленькой, понятной, управляемой системе.

Вывод

Этот апгрейд начался не с прихоти. Он начался с того, что MacBook Air M4 с 16 ГБ памяти перестал справляться с моим реальным рабочим режимом.

Я мог просто купить ноутбук помощнее. Но вместе со Стёпой/Codex я пошёл дальше и собрал новую конфигурацию: MacBook Air M5 32 ГБ как мобильный пульт, Mac mini M4 Pro 48 ГБ как постоянный devbox, плюс iPhone как мобильные точки управления.

Это не настройка ради настройки. Это переход от одного перегруженного ноутбука к распределённому рабочему контуру: мобильный MacBook, постоянный Mac mini, управляемая сеть, Codex как рабочий слой и iPhone как дополнительный пульт.

Самое приятное — теперь это можно развивать постепенно. Не в режиме “срочно всё перенести и молиться”, а нормальными инженерными пакетами: проекты, секреты, automation, аудиты, dev servers, NAS, VPS.

И да, в какой-то момент я просто подключил старенький iPhone SE и понял, что он тоже стал частью системы. Вот примерно тогда стало ясно: это уже не просто новый компьютер. Это маленькая личная инфраструктура для работы с ИИ, кодом и проектами.

По теме

• Статья: Как Codex стал моим техническим партнёром, а не просто чатиком для кода
• Блог: Один промпт, который заставляет Codex перепроверять себя — и реально улучшает результат
• База знаний: Codex от OpenAI — новая стандартная среда для работы с ИИ-агентами

Если вы тоже собираете личную рабочую станцию для Codex и проектов — с мобильной машиной, постоянным devbox и управлением с телефона — и не хотите потерять данные при переезде, давайте обсудим, с чего начать.

Связь со мной: t.me/pimenov · Мой канал: t.me/pimenov_ru