Никита

Не понятно, какого вида вы хотите добиться? Что значит "портфолио появляется у всех новых юзеров" ?

Если вы в моделе добавляете ForeingKey-поле, то доступ к нему вшаблоне возможен без дополнительных операций с контекстом во View.
Например

class User(models.Model):
    name = models.CharField(max_length=255)
    profile = models.OneToOneField('Profiles', null=True, blank=True, related_name='user_profile', on_delete=models.PROTECT)

class Profile(models.Model):
    age = models.IntegerField(blank=False, null=False)

в шаблоне или консоли вы можете использовать user.user_profile

{% for user in object_list %}
    User name: {{ user.name }}
         age: {{ user.user_profile.age }}
{% end for %}

во вью достаточно будет

class UsersListView(ListView):  # Страница поиска мастеров
    model = User
    template_name = "catalog/search-master.html"
    paginate_by = 30

Во вью можно использовать специальный класс для работы с формой - CreateView.

В этом view можно переопределить логику метода form_valid, создавать объект таблицы готовых подсетей. В этом методе будут доступны данные сохраненной и проверенной формы.

Можно вместо переопределения метода form_valid использовать метол save в форме SawnetForm, например так:

def save(self, commit=True):
    instance = super(SawnetForm, self).save(commit=False)
    # тут логика получения данных для сохранения в БД
    if commit:
        ReadySubnets.objects.update_or_create(
            ip_net=self.cleaned_data['ip_lan_24'],
            mask=self.cleaned_data['mask'],
        )
    return instance

Из документации:

These profile models are not special in any way - they are just Django models that happen to have a one-to-one link with a user model. As such, they aren’t auto created when a user is created, but a django.db.models.signals.post_save could be used to create or update related models as appropriate.

Это как раз из примера "расширения" стандартной модели пользователя.. дословно - объекты связанные с User через OneToOneField не создаются в момент создания пользователя, но у вас есть возможность сделать это через Сигналы.

У вас еще есть вариант "переопределить" стандартную модель пользователя, и тогда нужные поля будут сразу в User. Например:

class AuthUser(AbstractBaseUser, PermissionsMixin):
    email = models.EmailField(u'Электронная почта', unique=True)
    date_add = models.DateTimeField(u'Дата добавлен', auto_now_add=True)
    is_active = models.BooleanField(u'активен', default=True)
    employee = models.OneToOneField('person.Employies', null=True, blank=True, editable=True, verbose_name='Профиль сотрудника', on_delete=models.PROTECT)
    is_staff = models.BooleanField(u'администратор', default=False
                                   , help_text=u'определяет возможность входа в панель управления')
    roles = models.ManyToManyField(AuthUserRoles, verbose_name=u'Роли')
    objects = AuthUserManager()

Отдавайте статику Nginx'ом. Будет быстро и просто.

Собрать всю статику в одну папку нужно через manage.py collectstatic

Конфиг nginx для работы в паре с UWSGI сервером django

server {
    listen      80;
    server_name site.domain.ru;
    charset     utf-8;
    error_log   /usr/local/www/project/nginx_error.log;
    client_max_body_size 15m;

    location /robots.txt {
        alias /usr/local/www/project/robots.txt;
    }

    location /media  {
        alias /usr/local/www/project/src/media;  # your Django project's media files - amend as required
    }

    location /static {
        alias /usr/local/www/project/static; # your Django project's static files - amend as required
    }

    location /mediashare {
        alias /usr/local/www/project/mediashare; #
    }

    location / {
        uwsgi_read_timeout 600;
        uwsgi_send_timeout 600;
        uwsgi_pass  127.0.0.1:5004;
        include     uwsgi_params;
        add_header X-uri "$arg_page";
    }
}

Все у вас в кучу смешалось - Django, верстка, обработка событий.. Из django, в формате понятном браузеру, можно вывести все что угодно. Что бы понять, покажите хотя бы скриншот того, что вы хотите увидеть в итоге.

"при нажатии на стрелку.." - если это стрелка "самодельный" элемент страницы, что бы событие "нажатия" обрабатывалось, надо сделать "обработчик" этого события на Javascript, который может манипулировать списком данных, полученных от Django, на предварительной загрузке страницы в виде набора тэгов, или в JSON формате по Ajax запросу.

Можно немного модифицировать FormView из django.views.generic.edit, и во View наследоваться от нового класса.

Основная идея - в одном вью обрабатывать (создавать контекст, делать валидацию) для произвольного количества форм:

Пример использования views.py:

class CompanyCreatePrivateView(MultiFormCreate):
    template_name = 'company/company_create_private.html'
    formconf = {
        'company': {'formclass': CompanyCreatePrivateForm},
        'person': {'formclass': PersonCompanyCreateForm},
        'phone': {'formclass': PhoneNumberMaskedCreateForm},
        'companycontact': {'formclass': CompanyContactForm},
    }

В шаблоне контекст каждой формы будет не в form, а в forms.{имя формы}

Если создание объектов следующей формы зависит от создания объекта предыдущей - во вью придется переопределить метод forms_valid() и сохранять объекты "вручную".

P.S. готовый миксин MultiFormCreate не стал выкладывать, много текста..

Можно рассмотреть аналоги "микросервисов" - изолировать web-сервер "маленького" приложения (и связанную с ним разработку), а базу данных например оставить уже имеющуюся. Не придется писать API для обмена данными между микро и монолит сервисами, обмен будет сразу через БД. Вариант?